Migrate from Coolify to HostSSH

Coolify and HostSSH start from the same premise — your code runs on servers you control — and diverge on what happens next. This page covers the mechanical path from one to the other: what HostSSH reads, what it never touches, and where your data goes.

What HostSSH reads (and what it doesn't)

With a Coolify team API token, the importer previews the application: project, promoted commit, environment variables with their provenance, shared env, domains, and crons. The read is read-only — nothing in Coolify changes during preview. Secret values the API will not reveal are labelled needs-value and block the first deploy until you supply them, so a blank never ships silently.

Volumes and database contents have no download API on either side. They move over SSH with the existing mover: dumps and volume bytes land on the new host, then the app deploys pinned to the same commit it served on Coolify.

Why teams make the move

The recurring reason is portability scope. An application deploy moves code; a HostSSH capture moves the whole server — control-plane brain, every database, volumes, and system config — into one encrypted image, and a relocate rewrites the public IP across environment, databases, and configs on arrival. The first import gets you onto HostSSH; the capture is what makes every move after it a controlled cutover instead of a migration project.

Cutover checklist

1. Preview the Coolify app and confirm every env key is labelled copied or needs-value.
2. Fill needs-value keys; confirm the pinned commit matches what Coolify serves.
3. Apply: sealed env, first deploy, domains with TLS, crons firing.
4. Capture the new HostSSH server once — that image is your exit and your DR from here on.