Deploy a Web App
Use instavm deploy when you want the CLI to detect a project in the current directory, start it on a VM, and return a share URL.
Before you start
pip install instavm
instavm auth set-key
If you have not done the first deploy yet, start with Quickstart.
What instavm deploy detects
From the current directory, the CLI can infer:
- runtime
- package manager
- install and build commands
- start command
- port
- health path
- likely secrets that should be passed at deploy time
The zero-config path works best for straightforward static, Node.js, Python, Go, and Deno apps.
Preview the plan
cd /path/to/your/app
instavm deploy --plan
This dry run prints the detected runtime, install command, build command if present, start command, port, health path, and any secrets that will be prompted for.
Deploy the app
instavm deploy
A successful deploy prints the app slug, VM ID, share URL, instavm connect <vm_id> hint, and the cleanup command.
If your repo needs secrets, pass them at deploy time:
instavm deploy \
--env OPENAI_API_KEY="$OPENAI_API_KEY" \
--env ANTHROPIC_API_KEY="$ANTHROPIC_API_KEY"
instavm deploy is experimental. It is already useful for simple app repos, but you should expect to use overrides when the detected runtime, health check, or startup command is not quite right.
Useful flags
| Flag | Use it when |
|---|---|
--plan | You want to inspect the detected runtime and commands before provisioning a VM |
--env KEY=VALUE | The app needs secrets or runtime config during deploy |
--port | The detected port is wrong |
--health-path | The app exposes a health endpoint somewhere other than the detected path |
--start-command | You need to override the detected start command |
--install-command | You need a custom dependency install step |
--build-command | You need a custom build command |
--private | You do not want a public share created automatically |
--save-snapshot | You want a reusable snapshot after a successful deploy |
Manage the deployed VM
instavm ls
instavm connect <vm_id>
instavm rm <vm_id>
Use instavm connect when you want to inspect logs or the running filesystem over SSH. Use instavm rm when the deploy is no longer needed.
Manage shares directly
If you already have a VM and want to create or change a share manually:
instavm share create vm_abc123 3000 --public
instavm share set-private share_def456
instavm share set-public share_def456
instavm share revoke share_def456
See Shares & Custom Domains for the model behind these commands.
Custom domains
The CLI does not manage custom domains yet, so use the API directly:
curl -X POST https://api.instavm.io/v1/custom-domains \
-H "X-API-Key: instavm_sk_..." \
-H "Content-Type: application/json" \
-d '{"domain": "app.example.com", "share_id": "share_def456"}'
curl -X POST https://api.instavm.io/v1/custom-domains/{domain_id}/verify \
-H "X-API-Key: instavm_sk_..."
Use a coding agent when deployment should stay in the same conversation
If you are already building inside Claude Code, Codex, GitHub Copilot, Gemini CLI, or another coding agent, the Deploy from a Coding Agent guide is the better fit. The InstaVM skill keeps infra decisions like egress, shares, snapshots, and VM lifetimes inside the coding session.
Need lower-level control?
Use the SDK when you want to upload files yourself, run a custom service setup, or manage long-lived VMs explicitly:
Next steps
- Quickstart -- first deploy from a tiny static app
- CLI -- auth, config, and terminal-native commands
- Deploy from a Coding Agent -- use the InstaVM skill inside Claude Code, Codex, and similar tools
- Snapshots -- persist a working environment