Adopting an Existing Server

If you already run apps on a VPS outside of DeployOS — your own Compose stacks, a previous manual deploy setup — you can bring the whole server under DeployOS management without touching what's already running.

Coming from Coolify, Dokploy, CapRover, Dokku, or Render.com specifically? Importing From Other Platforms understands those platforms directly and is the faster path.

Scan

From a server's card, choose Scan. DeployOS opens an SSH session and inventories the box:

• OS, architecture, installed Docker and Compose versions.
• Whether the shared edge network exists.
• What's already listening on port 443 (Traefik, Caddy, Nginx, something else, or nothing) — and whether that means bootstrap should adopt or step aside.
• Firewall (ufw) status.
• Every running container, grouped by its Compose project label.
• Databases it can detect (Postgres, MySQL, MongoDB, Redis, MSSQL).
• A list of modernization advisories — things worth knowing about the server's current setup, each with a severity level.

Enlarge

Adopt

You have two options once you've scanned:

• Adopt individually — pick a specific running Compose project from the container table and adopt just that one as a managed app.
• Adopt everything — import every Compose project on the box as a managed app in one go, plus register any detected databases. This is the fastest path for "I want DeployOS to manage a server I've been running by hand."

Adopting doesn't redeploy or restart anything — it just teaches DeployOS about what's already there so you get logs, restarts, rollbacks, and monitoring for it going forward. Two things happen automatically, every time, whether the server is old or brand new to DeployOS:

• The reverse proxy gets linked correctly. A server that already had Traefik or Caddy running before DeployOS ever touched it almost never keeps that proxy's config in the folder DeployOS expects — it lives wherever the original setup put it. If that gap is left alone, deploys build and start containers fine but the route never reaches the actual running proxy, so the domain silently keeps serving whatever was there before. Adopting detects the real config directory and links DeployOS's path to it, so this can't bite you. You'll get a toast telling you whether it linked something, was already fine, or (rarely) couldn't detect it — in that last case, run Bootstrap on the server instead, which does the same detection with more room to install what's missing.
• Automatic Docker maintenance (nightly prune + health log) turns on, same as a fresh Bootstrap would set up.

After adopting

If the server was set up with a compatible apps.conf-style deploy script, adopting looks for it and prefills each app's repo, branch, domain and port automatically — nothing to fill in, deploy just works. Otherwise, adopted apps start with those fields blank, since DeployOS didn't create the container and doesn't know where the code came from; fill them in from the app's Config tab if you want DeployOS to redeploy from GitHub in the future. Either way, restart/logs/monitoring all work immediately — it's only deploy that needs a source, either detected automatically or filled in by hand.

💡 Tip — an adopted database defaults to a deployos user for its backups and health checks. If it actually uses different credentials, set them from the Databases page so backups work correctly.

Also useful for "bare" workloads DeployOS didn't recognize as a Compose project at all (a Node process running under pm2, for instance) — Scan surfaces these separately with a Containerize button that pre-fills the New App form with what it detected, so you can bring it under proper container management.