Migrate an app onto openpouch hosting

Move a Node app from wherever it runs today — with a stable URL from day one, your data along for the ride, and the old host untouched as your rollback anchor. Simple enough that your coding agent can run it end to end.

First, an honest distinction

openpouch has two lanes. The governed lane connects to a deployment you already have on another provider and adds agent-safe controls there — that is governance, not a migration. A migration means the app runs on openpouch hosting and has an openpouch URL. This page is about the second thing, and the CLI itself keeps the two apart: on a project that maps another provider, openpouch deploy refuses ambiguity and names the explicit migration move.

The migration, in three commands

1. Deploy onto openpouch with a named app.

   openpouch deploy . --app my-app --volume --env-file .env

   The first deploy mints your stable URL (--volume gives the app a persistent /data disk; --var/--env-file set its env — values never appear in logs or output). Every future deploy --app my-app updates the app behind the same URL: the new version is built and health-checked on a shadow first, so a failed update can never take down what's live — static content swaps with zero downtime, and a dynamic start failure rolls back automatically.
2. Bring the data.

   openpouch data push my-app ./exported-data

   Export from your current host with its own means — its shell, a dashboard download, or a temporary export route you add to the app (you own the code). data push then replaces the app's /data deterministically: the container is stopped for the write and restarted health-gated, so a SQLite file is never swapped under a running process. data ls verifies what's there; data pull is your tar backup — no lock-in, ever.
3. Verify, then hand over — and keep the exit open.

   openpouch verify

   Share the new URL once verify is green. Your old service keeps running untouched as the rollback anchor until you've confirmed the cutover in real use. Retiring it is deliberately a human decision — no tool or agent should make it for you.

What fits (and what doesn't, yet)

• Fits: Node.js servers (Express, Fastify, full-stack apps — build-on-deploy included) and static sites; on-disk data like SQLite or uploads via the /data volume.
• Honest limits: Node/static only (no other runtimes) · no managed databases — an external DB keeps working, it simply stays where it is · custom domains are on the way, your app lives at https://<name>.openpouch.sh for now.
• Plans: persistent /data volumes and always-on are part of paid plans (from $15/month, pricing); stable-URL apps need a free account — the migration itself is just these commands, not a sales call.

Why agents can run this

Every step above is a command with a machine-readable result and errors that say how to fix themselves — which is why a coding agent given "migrate this app; keep the data" can genuinely do it: deploy, set env, push data, verify, and report back with the new URL and the rollback plan. The repo's AGENTS.md (written by openpouch init) carries this exact workflow, so any harness finds it. Two things intentionally stay human: paying, and retiring the old host.