Move your project from Render (or anywhere) onto our Coolify server.

First, how our server works.

Four things to know before you touch any code.

Let the backend serve the frontend.

If you have a Vite/React frontend and an API, the simplest setup is to build the frontend and have the backend hand out those files. One container, one domain, no CORS. It's usually a few lines.

Default to one container. There's almost never a reason to run the frontend separately from the backend that serves its API, it's strictly more moving parts for the same result. If you think your project is the exception, that's a conversation to have with us before you build it that way, not after.

This is the real pattern from our own SmartChats migration, Express serving a built Vite app, with everything that isn't /api falling back to index.html so client-side routing still works.

import fs from "fs";
import path from "path";
import { fileURLToPath } from "url";

const __filename = fileURLToPath(import.meta.url);
const __dirname = path.dirname(__filename);

// after all your /api routes
const CLIENT_DIST_DIR = path.join(__dirname, "..", "..", "dist");
if (fs.existsSync(CLIENT_DIST_DIR)) {
  app.use(express.static(CLIENT_DIST_DIR));
  app.get(/^(?!\/api).*/, (_req, res) => {
    res.sendFile(path.join(CLIENT_DIST_DIR, "index.html"));
  });
}

app.listen(PORT, "0.0.0.0", () => { /* ... */ });

from fastapi.staticfiles import StaticFiles

# after all your /api routes
app.mount("/", StaticFiles(
    directory="frontend/dist", html=True
), name="site")

One for your laptop, one for the server.

On the server, Coolify's proxy decides which domain reaches which port, so the compose file there uses expose instead of mapping ports. That breaks on your machine, where there's no proxy, so keep two files that are otherwise identical.

services:
  app:
    build: .
    ports:
      - "3001:3001"   # host:container
    environment:
      PORT: 3001
      OPENAI_API_KEY: ${OPENAI_API_KEY}
      SUPABASE_URL: ${SUPABASE_URL}
      SUPABASE_SECRET_KEY: ${SUPABASE_SECRET_KEY}
    healthcheck:
      test: ["CMD", "node", "-e",
        "fetch('http://localhost:3001/').then(r=>process.exit(r.ok?0:1)).catch(()=>process.exit(1))"]
      interval: 30s
      timeout: 5s
      retries: 3
      start_period: 10s

services:
  app:
    build: .
    expose:
      - "3001"        # proxy routes your domain here
    environment:
      PORT: 3001
      OPENAI_API_KEY: ${OPENAI_API_KEY}
      SUPABASE_URL: ${SUPABASE_URL}
      SUPABASE_SECRET_KEY: ${SUPABASE_SECRET_KEY}
    healthcheck:
      test: ["CMD", "node", "-e",
        "fetch('http://localhost:3001/').then(r=>process.exit(r.ok?0:1)).catch(()=>process.exit(1))"]
      interval: 30s
      timeout: 5s
      retries: 3
      start_period: 10s

A health check block like the one above isn't strictly required, but Coolify (and Docker itself) can use it to know your container is actually ready, not just running.

Volumes: should you use one?

A volume is storage that survives a redeploy, anything written to a container's normal filesystem is gone the moment it restarts. If your app needs to keep something (uploads, generated files, a local database), you have two options.

Want a fully-loaded starting point?

A coolify-docker-compose.yml with every common option, commented, that you can delete down to what you need.

services:
  app:
    build: .
    expose:
      - "3001"                     # REQUIRED on the server: proxy routes here,
                                    # never use `ports:` in this file
    environment:
      PORT: 3001
      DATABASE_URL: ${DATABASE_URL}
      OPENAI_API_KEY: ${OPENAI_API_KEY}
      # add every env var your app reads; Coolify turns each ${VAR}
      # into a field you fill in on the server

    healthcheck:                   # optional, but lets Coolify/Docker know
      test: ["CMD", "node", "-e",  # the app is actually ready, not just running
        "fetch('http://localhost:3001/api/health').then(r=>process.exit(r.ok?0:1)).catch(()=>process.exit(1))"]
      interval: 30s
      timeout: 5s
      retries: 3
      start_period: 10s

    # optional: only if you talked to us about a volume first
    # volumes:
    #   - app-uploads:/app/uploads

  # optional: a second service, e.g. a worker or Redis
  # worker:
  #   build: .
  #   command: ["node", "dist/worker.js"]
  #   environment:
  #     DATABASE_URL: ${DATABASE_URL}

  # redis:
  #   image: redis:7-alpine
  #   expose:
  #     - "6379"

# optional: only if a volume was approved
# volumes:
#   app-uploads:

Docker, in plain words

Nine terms you'll run into.

Docker packages your app with everything it needs so it runs the same on your laptop and on the server. That's the whole point, and it's why local testing works.