38 Apps in One Day: Migrating an Empire from Replit to Coolify

The Hook

38 apps. One day. Roughly 120 pull requests across the empire. By the time the dust settled, every Replit-hosted project under our org had a migrate/coolify-clerk PR sitting in review, pre-staged for one-click Coolify deploy.

This is the candid version. What worked, what was a stub that did not need migrating, and what the recipe actually looks like when you repeat it 38 times in a day.

Why We Moved Off Replit

Replit was a great place to scaffold something at 1am. It is not where you want production infra to sit long-term.

The reasons stacked up:

• Vendor lock-in on the runtime. Replit's Nix layer, deployment targets, and proprietary databases meant every app carried a small but real "this only runs here" tax. Moving them was easier than continuing to pay it.
• Runtime quirks at scale. Cold starts, opaque crash loops, and a control plane we did not own. When 38 apps are all using the same hosting layer, every quirk multiplies.
• No infra parity with the rest of our stack. The serious DD apps already lived on Coolify (Hetzner) with Neon Postgres, Clerk auth, and Cloudflare DNS. Splitting hosting providers meant two debugging playbooks, two billing surfaces, two sets of secrets.
• Cost. We were paying for always-on Replit deployments for apps that get a few hundred hits a week. A Hetzner box running 30+ containers is cheaper than the Replit equivalent by an order of magnitude.

The decision was not "Replit bad." It was "one stack, one playbook, one bill."

The Recipe

Every migration followed the same shape, regardless of whether the app was Express or Next.js:

For Express + Vite + Drizzle apps:

1. Strip Replit-specific files (.replit, replit.nix, runtime polyfills).
2. Add Clerk for auth, replacing whatever Replit Auth shim was in place.
3. Move the database to Neon Postgres, point Drizzle at the new connection string.
4. Wrap it in a single-container Dockerfile that builds the Vite frontend and serves it from Express.
5. Add coolify.json plus health check endpoint.

For Next.js + Prisma apps:

1. Same Replit cleanup.
2. Clerk for auth.
3. Neon for the Postgres, Prisma migrations rerun against the new DB.
4. Single-stage Dockerfile using the standalone Next.js output.
5. Coolify config plus /api/health.

The single-container constraint was deliberate. Coolify is happiest when an app is one container with one port. No sidecars, no multi-service compose files unless the app genuinely needs them. Most did not.

The Honest Stats

The 38-app number sounds impressive until you break it down:

• 38 repos targeted. Pulled from the org-wide list of anything tagged or known to have Replit deployment history.
• ~16 were genuine app migrations. Real code, real users, real database, real port to do.
• ~9 were empty stubs. Repos scaffolded during a brainstorm, never actually built. The migration agent correctly skipped these and filed an "empty stub, no action" report.
• ~5 were monorepos. A single repo containing 2 to 4 deployable apps. Each got its own migrate/ branch with the apps split into separate Coolify services.
• ~4 were false-empties. Looked empty at first pass because the actual app lived in a subdirectory or behind a non-default branch. The agent flagged these for human review rather than guessing.
• ~4 were already migrated. Drift from a previous half-finished migration attempt. We closed those out and noted the existing deploy.

Total PRs opened across all categories: roughly 120. That includes the migration PRs, follow-up cleanup PRs (lockfile sync, env var fixes, health check tweaks), and a handful of chore: archive PRs for repos that should not have existed in the first place.

The Tooling

The fan-out was the interesting part.

The pipeline was three CLIs and one orchestrator:

• gh CLI for everything GitHub. Listing org repos, cloning, branch creation, PR open, PR comment, tagging reviewers. Every agent used gh and only gh.
• neonctl for spinning up Neon Postgres branches per app. New project, new connection string, dump it into the env file, done.
• Claude Code subagent fan-out as the orchestrator. The parent session held a queue of 38 repos. It dispatched one subagent per repo, each cloning to its own /tmp/<slug>/ directory to avoid the in-place collision problem we have hit before with 5+ parallel agents on the same checkout.

At peak, we had 8 to 10 subagents running concurrently. Each one followed the same replit-to-coolify skill: clone, audit, decide if migration is needed, apply the recipe or honest-skip, open a PR on a migrate/coolify-clerk branch, tag the reviewer, exit.

The honest-skip rule was load-bearing. Without permission to skip, an agent will hallucinate work to fill the silence. With it, the empty stubs and false-empties got flagged correctly instead of receiving fake migration PRs.

Ship Status

Every PR is sitting in review right now, tagged @devin-ai-integration for the automated review pass. The standing rule held across all 120 PRs: branch, PR, tag Devin, never direct-push to main.

Each migration PR is pre-staged for one-click Coolify deploy. The Dockerfile builds, the health check responds, the env vars are documented in the PR body. When Devin signs off and we merge, Coolify picks up the push and deploys.

We are merging in batches rather than all at once. Five to ten apps per evening, watch the Coolify queue, fix anything that breaks the build (usually a pnpm-lock.yaml sync issue, the recurring failure mode), move to the next batch.

What's Next

Once everything is on Coolify:

• Decommission Replit deployments after a 7-day grace period of dual-running.
• Standardize the observability layer. Every app gets the same Sentry config and the same /api/health shape, so the empire dashboard can poll one endpoint per app and get a real signal.
• Consolidate Neon projects. 38 separate Neon projects is too many. Group by tier and traffic so the free tier covers what it should and the paid tier covers what actually needs it.
• Write the replit-to-coolify skill into the standard scaffold. New apps should never touch Replit again. The skill is now part of the default scaffold path.

The interesting part of the day was not the migration itself. The recipe is boring once you have it. The interesting part was that 38 apps moved in a day because the orchestration was tight, the skip rule was honored, and every agent had the same playbook.

That is the leverage. Not the agents. The playbook the agents share.