Trigger v3 #2439

Flowko · 2024-06-10T21:01:37Z

Flowko
Jun 10, 2024

Hey @andrasbacsai , would love to know if coolify can handle the new trigger v3 self hosted version

https://trigger.dev/docs/v3/open-source-self-hosting

seems like there's alot of things to configure, would be awesome if we can have it run with one click on coolify, thank you

fdarian · 2024-06-29T16:54:13Z

fdarian
Jun 29, 2024

I manage to get it working using this docker_compose

⚠️ Make sure to recheck the generated env, things to highlight:

SERVICE_PASSWORD_32_<name>: I suggest replacing each secret using the openssl command

DEPLOY_REGISTRY_NAMESPACE: update with your own dockerhub username

Also set the Webapp's domain configuration, pointing to :3000. (will be autofilled by SERVICE_FQDN_WEBAPP)

x-postgres-env: &postgres-env
  POSTGRES_USER: $SERVICE_USER_POSTGRES
  POSTGRES_PASSWORD: $SERVICE_PASSWORD_POSTGRES
  POSTGRES_DB: '${POSTGRES_DB:-trigger}'
  POSTGRES_HOST: postgres

x-webapp-env: &webapp-env
  LOGIN_ORIGIN: $SERVICE_FQDN_WEBAPP
  APP_ORIGIN: $SERVICE_FQDN_WEBAPP
  DEV_OTEL_EXPORTER_OTLP_ENDPOINT: '${SERVICE_FQDN_WEBAPP}/otel'
  MAGIC_LINK_SECRET: $SERVICE_PASSWORD_32_MAGIC
  SESSION_SECRET: $SERVICE_PASSWORD_32_SESSION
  ENCRYPTION_KEY: $SERVICE_PASSWORD_32_ENCRYPTION
  DATABASE_URL: 'postgres://${SERVICE_USER_POSTGRES}:${SERVICE_PASSWORD_POSTGRES}@postgres:5432/${POSTGRES_DB}'
  DIRECT_URL: 'postgres://${SERVICE_USER_POSTGRES}:${SERVICE_PASSWORD_POSTGRES}@postgres:5432/${POSTGRES_DB}'
  RESEND_API_KEY: '${RESEND_API_KEY}'
  FROM_EMAIL: '${FROM_EMAIL}'
  RUNTIME_PLATFORM: docker-compose
  NODE_ENV: production
  PORT: 3000
  V3_ENABLED: true

x-worker-env: &worker-env
  PLATFORM_HOST: webapp
  PLATFORM_WS_PORT: 3000
  SECURE_CONNECTION: 'false'
  OTEL_EXPORTER_OTLP_ENDPOINT: '${SERVICE_FQDN_WEBAPP}/otel'

x-redis-env: &redis-env
  REDIS_HOST: redis
  REDIS_PORT: 6379
  REDIS_TLS_DISABLED: true

x-registry-env: &registry-env
  DEPLOY_REGISTRY_HOST: docker.io
  DEPLOY_REGISTRY_NAMESPACE: <update-me>

services:
  webapp:
    image: 'ghcr.io/triggerdotdev/trigger.dev:self-host-rc.3'
    restart: unless-stopped
    environment:
      <<: *webapp-env
      <<: *postgres-env
      <<: *redis-env
    depends_on:
      - postgres
      - redis
  postgres:
    image: 'postgres:16'
    restart: unless-stopped
    volumes:
      - 'postgres-data:/var/lib/postgresql/data/'
    environment:
      <<: *postgres-env
    healthcheck:
      test:
        - CMD-SHELL
        - 'pg_isready -U $${POSTGRES_USER} -d $${POSTGRES_DB}'
      interval: 5s
      timeout: 20s
      retries: 10
  redis:
    image: 'redis:7'
    restart: unless-stopped
    volumes:
      - 'redis-data:/data'
    environment:
      REDIS_HOST: redis
      REDIS_PORT: 6379
      REDIS_TLS_DISABLED: true
  docker-provider:
    image: 'ghcr.io/triggerdotdev/provider/docker:self-host-rc.3'
    restart: unless-stopped
    volumes:
      - '/var/run/docker.sock:/var/run/docker.sock'
    user: root
    depends_on:
      - webapp
    environment:
      <<: *worker-env
      <<: *registry-env
      PLATFORM_SECRET: $SERVICE_PASSWORD_64_PROVIDER
  coordinator:
    image: 'ghcr.io/triggerdotdev/coordinator:self-host-rc.3'
    restart: unless-stopped
    volumes:
      - '/var/run/docker.sock:/var/run/docker.sock'
    user: root
    depends_on:
      - webapp
    environment:
      <<: *worker-env
      <<: *registry-env
      PLATFORM_SECRET: $SERVICE_PASSWORD_64_COORDINATOR

1 reply

Flowko Jul 1, 2024
Author

oh wow thank you, would be awesome if you could add it as a PR, would help alot of people

DomNeuner · 2024-07-10T12:04:59Z

DomNeuner
Jul 10, 2024

Does this setup both the worker & webapp on the same server?

0 replies

LeoMavri · 2024-08-06T15:38:26Z

LeoMavri
Aug 6, 2024

Would love to see this instead of the current V2 templates.

0 replies

IRediTOTO · 2024-08-13T07:53:15Z

IRediTOTO
Aug 13, 2024

+1

0 replies

davidulman · 2024-08-13T19:59:23Z

davidulman
Aug 13, 2024

+1

0 replies

volfadar · 2024-08-18T18:20:25Z

volfadar
Aug 18, 2024

+1

0 replies

matthieu-beteille · 2024-08-21T20:40:55Z

matthieu-beteille
Aug 21, 2024

+1

0 replies

galer7 · 2024-09-05T17:25:25Z

galer7
Sep 5, 2024

I'm using this env generator and this docker-compose file and it's still failing: https://gist.github.com/galer7/777e8399713fa7f6b5e7cef9f53dca52

getting ERR_CONNECTION_REFUSED when accessing my SERVICE_FQDN_WEBAPP

1 reply

galer7 Sep 19, 2024

Posted a new comment on the gist that I linked above, but will post here as well:

If someone ever encounters this, I updated coolify to v4.0.0-beta.329 shortly after creating this gist and the simple trigger template from the resource catalog just works ™️!

donnutdev · 2024-09-18T18:49:51Z

donnutdev
Sep 18, 2024

@fdarian Hey! I just made a few changes to your docker-compose since the official v3 tag has been released.

x-postgres-env: &postgres-env
  POSTGRES_USER: $SERVICE_USER_POSTGRES
  POSTGRES_PASSWORD: $SERVICE_PASSWORD_POSTGRES
  POSTGRES_DB: '${POSTGRES_DB:-trigger}'
  POSTGRES_HOST: postgres

x-webapp-env: &webapp-env
  LOGIN_ORIGIN: $SERVICE_FQDN_WEBAPP
  APP_ORIGIN: $SERVICE_FQDN_WEBAPP
  DEV_OTEL_EXPORTER_OTLP_ENDPOINT: '${SERVICE_FQDN_WEBAPP}/otel'
  ELECTRIC_ORIGIN: 'http://electric:3000'
  MAGIC_LINK_SECRET: $SERVICE_PASSWORD_32_MAGIC
  SESSION_SECRET: $SERVICE_PASSWORD_32_SESSION
  ENCRYPTION_KEY: $SERVICE_PASSWORD_32_ENCRYPTION
  DATABASE_URL: 'postgres://${SERVICE_USER_POSTGRES}:${SERVICE_PASSWORD_POSTGRES}@postgres:5432/${POSTGRES_DB}'
  DIRECT_URL: 'postgres://${SERVICE_USER_POSTGRES}:${SERVICE_PASSWORD_POSTGRES}@postgres:5432/${POSTGRES_DB}'
  RESEND_API_KEY: '${RESEND_API_KEY}'
  FROM_EMAIL: '${FROM_EMAIL}'
  REPLY_TO_EMAIL: '${REPLY_TO_EMAIL}'
  WHITELISTED_EMAILS: '${WHITELISTED_EMAILS}'
  RUNTIME_PLATFORM: docker-compose
  NODE_ENV: production
  PORT: 3000
  V3_ENABLED: true

x-worker-env: &worker-env
  PLATFORM_HOST: webapp
  PLATFORM_WS_PORT: 3000
  SECURE_CONNECTION: 'false'
  OTEL_EXPORTER_OTLP_ENDPOINT: '${SERVICE_FQDN_WEBAPP}/otel'

x-redis-env: &redis-env
  REDIS_HOST: redis
  REDIS_PORT: 6379
  REDIS_TLS_DISABLED: true

x-registry-env: &registry-env
  DEPLOY_REGISTRY_HOST: docker.io
  DEPLOY_REGISTRY_NAMESPACE: <update-me>

services:
  webapp:
    image: 'ghcr.io/triggerdotdev/trigger.dev:v3'
    restart: unless-stopped
    environment:
      <<: *webapp-env
      <<: *postgres-env
      <<: *redis-env
    depends_on:
      - postgres
      - redis
  postgres:
    image: 'postgres:16'
    restart: unless-stopped
    volumes:
      - 'postgres-data:/var/lib/postgresql/data/'
    environment:
      <<: *postgres-env
    healthcheck:
      test:
        - CMD-SHELL
        - 'pg_isready -U $${POSTGRES_USER} -d $${POSTGRES_DB}'
      interval: 5s
      timeout: 20s
      retries: 10
  redis:
    image: 'redis:7'
    restart: unless-stopped
    volumes:
      - 'redis-data:/data'
    environment:
      REDIS_HOST: redis
      REDIS_PORT: 6379
      REDIS_TLS_DISABLED: true
  docker-provider:
    image: 'ghcr.io/triggerdotdev/provider/docker:v3'
    restart: unless-stopped
    volumes:
      - '/var/run/docker.sock:/var/run/docker.sock'
    user: root
    depends_on:
      - webapp
    environment:
      <<: *worker-env
      <<: *registry-env
      PLATFORM_SECRET: $SERVICE_PASSWORD_64_PROVIDER
  coordinator:
    image: 'ghcr.io/triggerdotdev/coordinator:v3'
    restart: unless-stopped
    volumes:
      - '/var/run/docker.sock:/var/run/docker.sock'
    user: root
    depends_on:
      - webapp
    environment:
      <<: *worker-env
      <<: *registry-env
      PLATFORM_SECRET: $SERVICE_PASSWORD_64_COORDINATOR
  electric:
    image: 'electricsql/electric:latest'
    restart: unless-stopped
    environment:
      DATABASE_URL: 'postgres://${SERVICE_USER_POSTGRES}:${SERVICE_PASSWORD_POSTGRES}@postgres:5432/${POSTGRES_DB}'
    depends_on:
      - postgres

6 replies

IRediTOTO Sep 19, 2024

do I just need paste this to docker compose in Coolify?

donnutdev Sep 21, 2024

do I just need paste this to docker compose in Coolify?

Yes, paste it in coolify and make sure all environment variables are filled and it should work properly

elysiumspark Sep 24, 2024

Thanks for posting this.. when I use this compose file it reloads everything fine except a postgresql (postgres:16) service, (and then of course the main Trigger service fails as well). If I inspect the logs of that failed container, it says:

Error: Database is uninitialized and superuser password is not specified.
You must specify POSTGRES_PASSWORD to a non-empty value for the
superuser. For example, "-e POSTGRES_PASSWORD=password" on "docker run".

====
But the postgres user and password are set in Coolify, and also tried to move them to the environment variables, and the main postgres seems to be running.

Chatgpt suggested I try to change the DEPLOY_REGISTRY_NAMESPACE as follows:
x-registry-env: &registry-env
DEPLOY_REGISTRY_HOST: ghcr.io
DEPLOY_REGISTRY_NAMESPACE: triggerdotdev

But that didn't work either, the same service fails (and then doesn't even show up in the containers).

donnutdev Sep 25, 2024

Error: Database is uninitialized and superuser password is not specified. You must specify POSTGRES_PASSWORD to a non-empty value for the superuser. For example, "-e POSTGRES_PASSWORD=password" on "docker run".

Hey, can you please tell me what coolify version you are running? In the past coolify has had some problems with the environment variables. Make sure you go into your service's Service Stack tab and make sure all the inputs are filled.

If this still produces the error, make sure these two variables are filled in the environment variables tab

If this still doesn't work, perhaps fill POSTGRES_PASSWORD and POSTGRES_USER manually in the environment variables.

elysiumspark Sep 25, 2024

Thanks for the reply...

Coolify v4.0.0-beta.341

Yes, I've set those two env variables as to the postgres user/pwd. The postgres service itself works, it's only the postgresql svc that fails. I've checked all the env variables; all are as they should be. Only the registry was a question mark as I don't use hub.docker for images. But using ghcr.io / triggerdotdev didn't work either.

I have several other things running fine (n8n, etc), and the v2 trigger out of the box from Coolify worked fine too. But upgrading to this v3 docker compose just didn't work. I even tried to fully redeployed it.

Mortalife · 2024-10-15T16:13:04Z

Mortalife
Oct 15, 2024

I just wanted to drop in and give some context that some users might find helpful on their journey of self-hosting trigger.dev v3.

I've got over 10,000 tasks ran on my instance that I've had live for a couple of months now and I've been supporting users over on the trigger.dev discord.

Some things I've seen crop up multiple times are the following:

V2 is a fundamentally different product to V3: If you've used V2 or are using V2 then it's best to approach this as if it's a completely new piece of software. V2 Supported users to run long lasting tasks on their own serverless functions, V3 pivots this to trigger.dev running your long running tasks in their own environment for you.
Trigger.dev isn't just a dashboard that runs some tasks, it's an orchestration platform:

This makes it a little harder to self-host than just running a template, you also need to consider where your docker images are going to live. The hosted platform abstracts this away from you by uploading your tasks into their private docker repo, when you self-host trigger, you need to provide this docker repository.

The guide provided by trigger suggests you use docker hub, or you build your tasks docker image on the machine that will be running your tasks so that the image is available. This is reasonable, but if you want to ensure your tasks are private or connect to an authenticated docker repository, then you'll likely have to do some additional (up to an including extending the docker-provider) to ensure trigger can pull your images.

Some things I don't see talked about but will probably impact your experience self-hosting trigger on Coolify.

Each task that is run by trigger (IE: every instantiation) is it's own docker run (for now - Trigger are working on reusable images).
This is great because it provides a level of isolation for your tasks - each runs with it own resources, in it's own environment - that means no noisy neighbours (unless you run up against your own server limits). What isn't talked about is that this leaves behind a large amount of docker containers that I haven't seen a mechanism (included in trigger.dev) to cleanup safely - I say safely because because of how some features of trigger.dev work (waiting for other tasks to finish executing etc, scheduling etc) will cause the image hang around to be used again, if you've got a long wait and you cleanup in-between you might have issues. If you're going to want long wait periods, I would recommend the hosted solution so you can cleanup proactively.
The docker-provider starts task images in the host network by default, this will likely cause issues unless you expose the port for the coordinator that it communicates with on startup.
By default, when a task is started within it's own docker container by the docker-provider it will be started on the host network. Once the container is running, it will need to communicate with the coordinator. Since the trigger.dev stack is usually ran as docker-compose within it's own network, this will mean that the ran task and the coordinator will be in different networks. The office docker-compose side steps this by exposing the services to the host localhost. You can do this too in coolify by ensuring the port for the coordinator is exposed. The port by default is 9020. The official docker-compose limits this to localhost with the following port assignment:

ports:
    - 127.0.0.1:9020:9020

I would instead suggest that you set the docker network for the docker-provider to the network of your service. The following env parameter should be added to your docker-provider env.

    - DOCKER_NETWORK=i304g4ogwk44ftckos4k6wos

I sometimes find that Coolify would not select the correct network for the traefik proxy, so the dashboard would periodically disappear. This is due to the default operation of proxy attempting to connect to the first network that is returned, sometimes that isn't a network the proxy has access to. You can set the network by adding the following label to the dashboard service which is the UUID for your service like above.

labels:
      - traefik.docker.network=i304g4ogwk44ftckos4k6wos

Github authentication - The current github authentication does not use the WHITELISTED_EMAILS parameter so if used there would be no way to prevent random people from authenticating against your trigger instance. This is somewhat mitigated by the need for the user to upload to your docker repo, but if you don't have that authenticated as seems to be the default, even that isn't insurmountable. Recommendation, use email authentication with WHITELISTED_EMAILS.
Large task payloads - You need to set an S3 compatible bucket if you want to trigger tasks with a payload over 512kb otherwise you will get an error, this involves setting 3 additional env parameters on the dashboard service. I've not run up against this limit myself but others have. You can read more about the envs required here
Self hosted CLI - You need to point your cli to your hosted instance, this includes logging in with your self-hosted url which is then saved into a profile for you to use. If you later go on to deploy your code via a CI/CD pipeline where this profile does not exist, you will need to set the 2 env parameters to configure the CLI. More information can be found here
Horizontal expansion - I've run out of server capacity, now what? Currently trigger.dev is only setup to support a single provider, so if you are hitting the limits of your server capacity with your current workload you've going to need to vertically scale your compute through either moving the docker-provider to it's own larger server (and the additional configuration required to ensure it can communicate with the rest of the stack), or moving your entire stack to a larger server. They do have a Kubernetes provider that they use in house which might be an option if you have the skills to support this, but I don't believe it's documented for external use. That all said, I believe there is an active piece of work to make it so this scales, so watch this space.

This is all for now, if I remember anything else I'll update this post.

The docker-compose I use is as follows:
Notes:

There is a reason I haven't submitted this as a PR as a template, I don't personally feel that trigger is something that works well as a one click install as it requires additional setup that users need to be aware of. I am working on a template that includes a pre-wired up repository as part of the stack so will make it much more user friendly to just deploy - the user will still need to setup resend api which still might be too much for some people.
I opted not to use the shared env and instead looked at which env's were required for each service.
This uses ENFORCE_MACHINE_PRESETS=true to ensure resources as specified here are enforced, they are ignored by default.

You will need to set the following env's once the stack is setup:

Emails you want to allow to sign up: WHITELISTED_EMAILS
Your resend api key, to allow email sending for login: RESEND_API_KEY
Emails you want to be admins: ADMIN_EMAILS
Email you want to send login emails from (must be authenticated within resend): REPLY_TO_EMAIL
The host of your docker repository: DEPLOY_REGISTRY_HOST
The namespace within your docker repository: DEPLOY_REGISTRY_NAMESPACE

To deploy code to your instance you will need to run the following command where you have access to your code, and permission/setup for your docker repository:

pnpm dlx trigger.dev@latest deploy --api-url https://trigger-324234.yourcoolifyserver.com --skip-update-check --self-hosted --push

This includes --skip-update-check to prevent it failing if a new version of the cli has been released and you've not restarted your trigger stack.

If you're running this in a CI/CD pipeline then you will need to ensure the following env parameters are set:
TRIGGER_API_URL & TRIGGER_ACCESS_TOKEN see here

I have additional configurations which allow me to use authenticated AWS Container Repository, if anybody wants that, I'll make it available.

services:
  webapp:
    image: 'ghcr.io/triggerdotdev/trigger.dev:${TRIGGER_VERSION:-v3}'
    environment:
      - SERVICE_FQDN_TRIGGER_3030
      - 'RESEND_API_KEY=${RESEND_API_KEY}'
      - 'LOGIN_ORIGIN=${SERVICE_FQDN_TRIGGER}'
      - 'APP_ORIGIN=${SERVICE_FQDN_TRIGGER}'
      - 'DEV_OTEL_EXPORTER_OTLP_ENDPOINT=${SERVICE_FQDN_TRIGGER}/otel'
      - PORT=3030
      - 'POSTGRES_DB=${POSTGRES_DB:-postgres}'
      - 'POSTGRES_PASSWORD=${SERVICE_PASSWORD_64_POSTGRES}'
      - 'POSTGRES_PORT=${POSTGRES_PORT:-5432}'
      - 'POSTGRES_USER=${POSTGRES_USER:-postgres}'
      - 'DATABASE_URL=postgresql://${POSTGRES_USER:-postgres}:${SERVICE_PASSWORD_64_POSTGRES}@postgres:${POSTGRES_PORT:-5432}/${POSTGRES_DB:-postgres}'
      - 'DIRECT_URL=postgresql://${POSTGRES_USER:-postgres}:${SERVICE_PASSWORD_64_POSTGRES}@postgres:${POSTGRES_PORT:-5432}/${POSTGRES_DB:-postgres}'
      - REMIX_APP_PORT=3030
      - NODE_ENV=production
      - RUNTIME_PLATFORM=docker-compose
      - V3_ENABLED=true
      - TRIGGER_TELEMETRY_DISABLED=1
      - INTERNAL_OTEL_TRACE_DISABLED=1
      - INTERNAL_OTEL_TRACE_LOGGING_ENABLED=0
      - REDIS_HOST=redis
      - REDIS_PORT=6379
      - REDIS_TLS_DISABLED=true
      - 'WHITELISTED_EMAILS=${WHITELISTED_EMAILS:-authorized@yahoo\.com|authorized@gmail\.com}'
      - 'ADMIN_EMAILS=${ADMIN_EMAILS:-admin@example\.com|another-admin@example\.com}'
      - 'FROM_EMAIL=${FROM_EMAIL:[email protected]}'
      - 'REPLY_TO_EMAIL=${REPLY_TO_EMAIL:[email protected]}'
      - 'DEFAULT_ORG_EXECUTION_CONCURRENCY_LIMIT=${DEFAULT_ORG_EXECUTION_CONCURRENCY_LIMIT:-300}'
      - 'DEFAULT_ENV_EXECUTION_CONCURRENCY_LIMIT=${DEFAULT_ENV_EXECUTION_CONCURRENCY_LIMIT:-100}'
      - 'MAGIC_LINK_SECRET=${SERVICE_BASE64_MAGIC_LINK}'
      - 'SESSION_SECRET=${SERVICE_BASE64_SESSION}'
      - 'ENCRYPTION_KEY=${SERVICE_BASE64_ENCRYPTION}'
      - 'PROVIDER_SECRET=${SERVICE_PASSWORD_64_PROVIDER}'
      - 'COORDINATOR_SECRET=${SERVICE_PASSWORD_64_COORDINATOR}'
      - 'DEPLOY_REGISTRY_HOST=${DEPLOY_REGISTRY_HOST:-docker.io}'
      - 'DEPLOY_REGISTRY_NAMESPACE=${DEPLOY_REGISTRY_NAMESPACE:-trigger}'
      - 'HTTP_SERVER_PORT=${HTTP_SERVER_PORT:-9020}'
      - 'COORDINATOR_PORT=${HTTP_SERVER_PORT:-9020}'
      - 'ELECTRIC_ORIGIN=http://electric:3000'
    healthcheck:
      test:
        - CMD
        - node
        - '-e'
        - "require('http').get('http://127.0.0.1:3030/healthcheck', (r) => {if (r.statusCode !== 200) process.exit(1); else process.exit(0); }).on('error', () => process.exit(1))"
      interval: 5s
      timeout: 5s
      retries: 5
      start_period: 30s
    restart: unless-stopped
    depends_on:
      - postgres
      - redis
    networks:
      - webapp
  postgres:
    image: 'postgres:16'
    restart: unless-stopped
    healthcheck:
      test:
        - CMD-SHELL
        - 'pg_isready -U postgres'
      interval: 3s
      timeout: 3s
      retries: 10
    volumes:
      - 'postgres-data:/var/lib/postgresql/data/'
    environment:
      - 'POSTGRES_DB=${POSTGRES_DB:-postgres}'
      - POSTGRES_PASSWORD=$SERVICE_PASSWORD_64_POSTGRES
      - 'POSTGRES_PORT=${POSTGRES_PORT:-5432}'
      - 'POSTGRES_USER=${POSTGRES_USER:-postgres}'
    networks:
      - webapp
    command:
      - '-c'
      - wal_level=logical
  redis:
    image: 'redis:7'
    restart: unless-stopped
    healthcheck:
      test:
        - CMD-SHELL
        - 'redis-cli ping | grep PONG'
      interval: 1s
      timeout: 3s
      retries: 5
    volumes:
      - 'redis-data:/data'
    networks:
      - webapp
  docker-provider:
    image: 'ghcr.io/triggerdotdev/provider/docker:${TRIGGER_VERSION:-v3}'
    restart: unless-stopped
    volumes:
      - '/var/run/docker.sock:/var/run/docker.sock'
    user: root
    healthcheck:
      test:
        - CMD
        - node
        - '-e'
        - "require('http').get('http://127.0.0.1:9020/health', (r) => {if (r.statusCode !== 200) process.exit(1); else process.exit(0); }).on('error', () => process.exit(1))"
      interval: 5s
    networks:
      - webapp
    depends_on:
      - webapp
    environment:
      - PLATFORM_HOST=webapp
      - PLATFORM_WS_PORT=3030
      - SECURE_CONNECTION=false
      - 'OTEL_EXPORTER_OTLP_ENDPOINT=${SERVICE_FQDN_TRIGGER}/otel'
      - 'PLATFORM_SECRET=${SERVICE_PASSWORD_64_PROVIDER}'
      - 'REGISTRY_HOST=${DEPLOY_REGISTRY_HOST:-docker.io}'
      - 'REGISTRY_NAMESPACE=${DEPLOY_REGISTRY_NAMESPACE:-trigger}'
      - 'FORCE_CHECKPOINT_SIMULATION=${FORCE_CHECKPOINT_SIMULATION:-0}'
      - 'HTTP_SERVER_PORT=${HTTP_SERVER_PORT:-9020}'
      - 'COORDINATOR_PORT=${HTTP_SERVER_PORT:-9020}'
      - ENFORCE_MACHINE_PRESETS=true
  coordinator:
    image: 'ghcr.io/triggerdotdev/coordinator:${TRIGGER_VERSION:-v3}'
    restart: unless-stopped
    user: root
    volumes:
      - '/var/run/docker.sock:/var/run/docker.sock'
    healthcheck:
      test:
        - CMD
        - node
        - '-e'
        - "require('http').get('http://127.0.0.1:${HTTP_SERVER_PORT:-9020}/health', (r) => {if (r.statusCode !== 200) process.exit(1); else process.exit(0); }).on('error', () => process.exit(1))"
      interval: 5s
    networks:
      - webapp
    ports:
      - '9020:9020'
    depends_on:
      - webapp
    environment:
      - PLATFORM_HOST=webapp
      - PLATFORM_WS_PORT=3030
      - SECURE_CONNECTION=false
      - 'OTEL_EXPORTER_OTLP_ENDPOINT=${SERVICE_FQDN_TRIGGER}/otel'
      - 'PLATFORM_SECRET=${SERVICE_PASSWORD_64_COORDINATOR}'
      - 'HTTP_SERVER_PORT=${HTTP_SERVER_PORT:-9020}'
      - 'COORDINATOR_HOST=${COORDINATOR_HOST:-127.0.0.1}'
      - 'COORDINATOR_PORT=${HTTP_SERVER_PORT:-9020}'
      - 'REGISTRY_HOST=${DEPLOY_REGISTRY_HOST:-docker.io}'
      - 'REGISTRY_NAMESPACE=${DEPLOY_REGISTRY_NAMESPACE:-trigger}'
      - 'FORCE_CHECKPOINT_SIMULATION=${FORCE_CHECKPOINT_SIMULATION:-0}'
  electric:
    image: 'electricsql/electric:latest'
    restart: '${RESTART_POLICY:-unless-stopped}'
    environment:
      - 'DATABASE_URL=postgresql://${POSTGRES_USER:-postgres}:${SERVICE_PASSWORD_64_POSTGRES}@postgres:${POSTGRES_PORT:-5432}/${POSTGRES_DB:-postgres}?sslmode=disable'
    networks:
      - webapp
    depends_on:
      - postgres
    ports:
      - '3061:3000'

2 replies

jeffersonsc Nov 27, 2024

Thanks for shared the experience in that issue.

I run my trigger in coolify sucessfly.

Thanks.

IRediTOTO Dec 8, 2024

Thanks for shared the experience in that issue.

I run my trigger in coolify sucessfly.

Thanks.

Is it run on production? Can you share your config?

IRediTOTO · 2024-12-08T13:25:24Z

IRediTOTO
Dec 8, 2024

I have this error

 {"message":"connect_error: Error: websocket error","$name":"socket-coordinator","$level":"error","namespace":"coordinator","host":"trigger","port":3030,"secure":false,"extraHeaders":{"x-supports-dynamic-config":"yes"}}

{"message":"connect_error: Error: websocket error","$name":"socket-provider","$level":"error","namespace":"provider","host":"trigger","port":3030,"secure":false,"extraHeaders":{"x-trigger-provider-type":"docker"}}
 {"message":"connect_error: Error: websocket error","$name":"socket-shared-queue","$level":"error","namespace":"shared-queue","host":"trigger","port":3030,"secure":false}

0 replies

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Trigger v3 #2439

{{title}}

{{editor}}'s edit

{{editor}}'s edit

Replies: 11 comments 10 replies

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{editor}}'s edit

{{editor}}'s edit

{{title}}

{{title}}

{{title}}

Select a reply

Trigger v3 #2439

Replies: 11 comments · 10 replies

Flowko Jul 1, 2024 Author

Replies: 11 comments 10 replies

Flowko Jul 1, 2024
Author