Coolify to Temps: Manual Migration and DNS Cutover

For the automatic import wizard, see Migrate from Coolify to Temps: it connects to your Coolify instance, discovers its apps and databases, and recreates them as Temps projects. This guide covers what the wizard doesn't: the manual migration for full control, a zero-downtime DNS cutover, and a checklist to verify the result. Budget 5–10 minutes with the wizard for a single-service app, 30–60 minutes by hand, and 1–2 hours for multi-service projects or a zero-downtime cutover.

Quick answer:

• What moves automatically: With the import wizard: the project and its build config, environment variables, custom domains, and PostgreSQL, MySQL/MariaDB and MongoDB data when the database's public port is enabled in Coolify. With the manual path below: just your Docker Compose/Dockerfile definition, since Temps deploys the same shape.
• What still needs a manual step: DNS cutover; database data unless the database's public port is enabled; Redis data (the service is created empty); one-click services from Coolify's catalog (deploy their Compose file); and files in persistent volumes (move them to S3 storage, since Temps app containers have no volumes).
• Typical time: 5–10 minutes with the wizard for a single-service app; 30–60 minutes by hand; 1–2 hours for multi-service projects or a zero-downtime cutover.
• What you gain on arrival: Error tracking with a Sentry-compatible DSN, session replay, uptime monitoring and app-level web analytics, in the same binary that deploys your app.

Why Teams Migrate from Coolify to Temps

Three reasons come up most often. For the full feature and pricing comparison, see Temps vs Coolify.

The Observability Gap Compounds in Production

Coolify deploys containers well. Since v4.4 (October 2026) it also offers opt-in, per-server traffic analytics at the proxy level — requests, visitors, latency, referrers. What it still doesn't include is error tracking, session replay, uptime checks or app-level product analytics; those come as separate services. For a production app that means assembling and paying for a separate stack. The usual hosted combination — Plausible $9 + Sentry Team $26 + LogRocket from $176 — comes to about $211/month (prices as of October 2026; see the Coolify pricing breakdown), and someone has to maintain the integrations.

Previews Come With Observability Built In

Both platforms build a preview for each branch or pull request once previews are switched on for the project; Coolify also needs its GitHub App or a repository webhook. The difference on Temps is that each preview comes with error tracking and session replay already wired in, so you can see what broke on a branch before it merges.

Multi-Node Scaling Means Assembling Your Own Networking

Coolify's multi-server support deploys to extra servers over SSH, with an external load balancer in front. Temps joins worker nodes to one control plane with temps join over a private network you provide (a VPC, a VPN or Tailscale) and schedules containers across them, without a Kubernetes layer.

What's Different Before You Start

For a migration, only a few differences matter; the Temps vs Coolify comparison covers the rest.

The service-template gap is the one place Coolify still wins outright: if your stack leans on a lot of one-click open-source tools, Coolify's library is deeper. For everything you're deploying yourself, the migration is close to a lateral move on the deploy step — the difference shows up in what's running alongside it.

The Manual Path, Step by Step

Prefer the automated route? See Migrate from Coolify — connect, discover, review the plan, execute. The walkthrough below is for doing it by hand instead, and assumes a Dockerfile or Docker Compose app. Apps that Coolify builds with Nixpacks or Railpack have neither file; they deploy with a Temps preset or a Dockerfile you add.

Option A: Fresh Redeploy (fastest, brief downtime acceptable)

Step 1: Export your environment variables

Coolify has no documented CLI export for environment variables — copy them from your project's Environment Variables section in the Coolify dashboard into a .env file. Coolify offers both a form-based "Normal View" and a plain-text .env-format "Developer View" for this — the Developer View is faster to copy from in bulk.

Step 2: Install Temps on your server

curl -fsSL https://temps.sh/deploy.sh | bash

This can be the same server Coolify is running on (if you're retiring Coolify entirely) or a new one.

Step 3: Log in and import your project

bunx @temps-sdk/cli login https://console.<your-server-ip-dashed>.sslip.io

Use the console URL the installer printed (or your own domain). The CLI opens a browser approval page — no password is typed into the terminal.

Open the Temps dashboard, choose New Project → Import from GitHub (or point it at your Docker Compose file directly), select your repository, paste in the environment variables from Step 1, and deploy. Temps auto-detects Next.js, Vite, Python, Go, Rust, Java and Docker Compose projects from the repository files, and deploys your existing Dockerfile as-is. For a plain Node server (Express, NestJS), pick the Node preset yourself.

Step 4: Migrate your database

# From your Coolify database container
pg_dump -U youruser -d yourdb > backup.sql

# Into your new Temps-managed Postgres instance
psql -U youruser -d yourdb < backup.sql

Create the Postgres service in Temps and link it to your project first — Temps doesn't provision databases automatically. Linking injects POSTGRES_URL (plus POSTGRES_HOST, POSTGRES_PORT and friends), so point your app at that or map it to the variable name your code expects. Temps doesn't run your schema migrations on deploy; run them once as a separate step. Substitute your database's native dump/restore tool if you're not on Postgres.

Step 5: Update DNS

Point your domain's A record (or CNAME) at the new Temps deployment. TLS certificates provision automatically via Let's Encrypt once DNS resolves.

Migration time: 30–60 minutes

Option B: Parallel Cutover (zero downtime)

For apps that can't tolerate a gap, run both deployments side by side before switching:

1. Deploy to Temps following Steps 1–4 above, but don't touch DNS yet — your Coolify deployment keeps serving production traffic.
2. Verify the Temps deployment on its generated URL (<app>.<your-server-ip-dashed>.sslip.io, unless you've already added a domain): check that health checks are passing, run through your app's core flows, and confirm the database migrated cleanly.
3. Point a staging subdomain at the Temps deployment and test against real traffic patterns for a day or two if your app is complex enough to warrant it.
4. Cut DNS over to Temps once you're confident. Keep the Coolify deployment running (but not receiving traffic) for a day as a rollback option before decommissioning it.

Migration time: 1–2 hours, spread over the verification window

What Changes, What Stays the Same

Your Docker Compose file or Dockerfile doesn't need to change — that's the part of the migration that just works. (An app Coolify built with Nixpacks or Railpack needs a Temps preset or a Dockerfile instead.) What's different is everything around it.

Stays the Same

• Docker Compose service definitions
• Dockerfile build steps
• Application code — no framework-level changes required
• Git-push deployment workflow

Changes

How to Verify Your Migration

Run through this before routing production traffic to the new deployment.

Functionality

• All routes load (SSR, SSG, static, API routes)
• Database queries return expected data
• Authentication flows work
• Background jobs / cron tasks (if any) are running on the new deployment, not still on Coolify

Operations

• SSL certificate valid and auto-renewing
• All environment variables present and correct
• Health checks passing: Temps probes every 5 seconds and switches traffic only after 2 consecutive successful responses; if the app isn't healthy within the startup timeout (5 minutes by default) the deploy fails and the previous version keeps serving (how health checks work)
• Analytics and error tracking receiving data — confirm in the Temps dashboard

DNS

• Domain pointing to the new Temps deployment
• Old Coolify DNS records removed (or the old deployment decommissioned) once you're confident

Common Migration Issues and Fixes

These are general Docker-deployment troubleshooting patterns, not Coolify- or Temps-specific documented issues — start here, but check the Temps troubleshooting guide or ask in the community if your case doesn't match.

Build fails on Temps but worked on Coolify

If your Dockerfile builds cleanly in isolation (docker build . on your own machine) but fails during deploy, compare build-time environment variables and build arguments between the two platforms — a variable your Coolify setup had configured that Temps doesn't yet have is the most common gap.

Database connection refused after cutover

Confirm your connection string points at the new Temps-managed database, not the old Coolify one. A stale DATABASE_URL is the usual culprit: Temps' linked Postgres service injects POSTGRES_URL, so either read that variable or set DATABASE_URL to its value.

Health checks failing immediately after deploy

Verify your app actually listens on the port Temps expects and binds to 0.0.0.0 rather than localhost — a common gap when a Dockerfile was written for local development first. This isn't Temps- or Coolify-specific; it trips up container deployments on any platform.

Uploaded files or volume data missing after cutover

Temps app containers have no persistent volumes, and the import wizard does not move files out of Coolify's Docker volumes. Before cutting over, copy uploads and other file data to object storage such as Temps managed S3 and point the app at it. A Docker Compose project can still declare named volumes, but their contents have to be copied across by hand and Temps backups don't cover them.

Preview deployments not appearing

As on Coolify, previews have to be switched on for the project first — see Set up preview deployments. If they're enabled and still not showing up, check that the GitHub App integration has access to the repository.

When to Stay on Coolify

Migrating isn't the right call for every team. Stay on Coolify if:

• You lean heavily on its template library — 360+ one-click templates for third-party tools is real, and Temps doesn't try to match that catalog.
• You've already built your own observability stack — if Sentry, a session-replay tool and UptimeRobot are already wired up and working, and Coolify's new proxy-level traffic analytics covers your analytics needs, switching saves you less.
• Multi-node isn't in your near-term plans — if you're running a single server, Temps' multi-node scheduling doesn't matter yet.

If none of those describe your setup, the migration is likely worth the afternoon it takes. Still comparing options? The self-hosted deployment platforms roundup covers the wider field.

See what you'd save — and whether a free migration audit fits

Answer three quick questions to get your estimated annual savings. Teams paying $750+/mo across cloud + developer SaaS qualify for a free 30-minute migration audit where we map every line of your bill to a Temps equivalent and hand you a migration plan. Smaller teams get a self-serve path to the same outcome.

Frequently Asked Questions

Can I migrate from Coolify to Temps?

Yes — Temps has a built-in import wizard that connects to your Coolify instance, discovers its apps and databases, and creates matching projects and managed services automatically. Custom domains are imported from each app's domain list, and TLS is issued once DNS points at Temps. PostgreSQL, MySQL/MariaDB and MongoDB content copies automatically when the database's public port is enabled in Coolify; otherwise it moves via a standard dump and restore such as pg_dump/pg_restore. Redis data, one-click services from Coolify's catalog and files in Docker volumes are not moved. You can also do the whole migration by hand — see the manual walkthrough above — if you'd rather have full control over each step.

How long does a Coolify to Temps migration take?

5–10 minutes with the import wizard for a single-service app; 30–60 minutes by hand; 1–2 hours for multi-service projects or a zero-downtime parallel cutover.

Will my Docker Compose file need changes to run on Temps?

In most cases, no. Temps deploys the same Docker Compose and Dockerfile shape Coolify does. The parts that change are environment variable management, database migration, and DNS — not the container definitions themselves.

What does Temps include that Coolify doesn't?

Sentry-compatible error tracking, session replay, uptime monitoring and app-level web analytics. Coolify covers deployment, server metrics and, since v4.4 (October 2026), opt-in proxy-level traffic analytics. Adding app-level analytics, error tracking and session replay on top of Coolify with hosted tools costs about $211/month (Plausible $9 + Sentry Team $26 + LogRocket from $176, as of October 2026; see the Coolify pricing breakdown).

Is Coolify cheaper than Temps?

Coolify is free to self-host under Apache 2.0, and Temps under a dual MIT / Apache 2.0 license — you pay only for the server you already run it on, either way. Coolify Cloud is $5/month including 2 servers, +$3/month per extra server; Temps Cloud, a hosted control plane for your own servers, is coming soon from $29/month (2 server slots). The bigger cost difference shows up once you account for the observability tools Coolify doesn't include.

Do I lose my Coolify service templates when I migrate?

You lose access to Coolify's one-click template catalog specifically, but anything deployed from a Docker Compose file continues to work on Temps the same way. If a tool you rely on is only available as a Coolify template with no public Compose file, that's the one case worth checking before you commit to migrating it.

Next Steps

Start by listing what's actually running on your Coolify instance:

docker compose ps

A single-service app with one database is a same-afternoon migration. Anything larger — multiple services, background workers, a sizable database — is worth scheduling a maintenance window and following the parallel-cutover path above.

Related guides:

• Temps vs Coolify
• Postgres HA and Multi-Node: Coolify vs Temps
• Coolify Review 2026
• Temps vs Coolify vs Netlify (2026): Self-Hosted PaaS Compared
• 5 Best Coolify Alternatives
• Coolify Pricing 2026 Explained
• How to Migrate from Vercel to Self-Hosted

This guide covers Docker Compose and Dockerfile-based projects; apps Coolify builds with Nixpacks or Railpack deploy with a Temps preset or a Dockerfile. Test thoroughly against a staging environment before cutting over production traffic.