Deploy a Repo with Its Own Database (Bring Your Own Compose)

The Custom app option (deploy from a GitHub repository) always runs a single container. Some projects are not a single process. They declare their own Postgres, Redis or several services together, usually with a docker-compose.yml already in the repo. For those, use Bring Your Own Compose.

When you need this instead of Custom app

If the project's README or setup instructions mention running docker compose up, or it needs a database connection just to start, a single container has nowhere to get that from. It will build successfully and then fail or crash-loop every time.

How it works

Open Templates in your dashboard and paste a full docker-compose.yml. Every service it declares (your app, Postgres, Redis, a worker, whatever the project needs) deploys together as one stack, with real values filled in for any placeholder passwords or secrets the file expects. If the project ships its own compose file for self-hosting, start from that instead of writing one from scratch. Check which branch it is on, since it is not always the repo's default branch.

What is not allowed

Each service runs as an unprivileged container on shared infrastructure, so host networking, privileged mode and host-path bind mounts are not supported.

Delete every ports: line as well. A published host port such as "8080:8080" tries to claim that port on the shared server directly. It can collide with another app, and the deploy fails with port is already allocated. Services still reach each other by name without it, and whichever one needs to be public gets its URL from FlyNode's domain routing instead.

Common mistake

A project's own self-hosting compose file almost always publishes a port for every service, because it was written assuming it owns the whole machine. Before pasting one in, open it and delete every ports: block first.

Example

services:
  app:
    build: .
    environment:
      DATABASE_URL: postgres://app:app@db:5432/app
      REDIS_URL: redis://cache:6379
    depends_on:
      - db
      - cache

  db:
    image: postgres:16-alpine
    environment:
      POSTGRES_USER: app
      POSTGRES_PASSWORD: app
      POSTGRES_DB: app
    volumes:
      - db-data:/var/lib/postgresql/data

  cache:
    image: redis:7-alpine

volumes:
  db-data:

Services reach each other by name (db, cache), the same way they would with plain Docker Compose anywhere else.

Deploying a single-process repo instead? See Deploy a GitHub Repository.