Docker

Deploy a Docker App to an Offshore VPS

Deploy a compatible container on an offshore VPS with the Impreza Agent online. Configure the app route, persistent data and recovery plan before relying on the deployment.

Impreza can deploy a compatible container image, Dockerfile project or Compose stack on your own supported VPS. The Impreza Agent must be installed and online. HTTP apps need a valid route and hostname for managed HTTPS; other workloads need their own network configuration. Start with the source, resource requirements and data paths.

Three ways to ship

  • A public image. Choose an accessible image compatible with the server architecture, resources and runtime requirements
  • A Dockerfile in git. Build straight from your repo, public or private
  • A compose manifest. Bring a multi-service stack as one app

Deploy it

Get a VPS

Order an offshore VPS with the Impreza Agent and wait until it is online. Check CPU, memory and disk capacity for the app, image layers, build workspace and backup or restore work. No-KYC signup and crypto payments are available.

Choose your source

For a published image, give the image reference. To build from source, give the git URL and branch, plus a Dockerfile path if it is not at the repo root. For a multi-service stack, hand over the compose manifest instead.

Set the runtime details

Name the deployment, set the port your container listens on, and choose a hostname you control for managed HTTPS. A custom hostname must pass the ownership check below; the free managed subdomain follows its own allocation. Adjust the CPU and memory limits if the defaults are tight, and pass configuration as environment variables.

Persist your data

Map the paths that hold state, such as database files and uploads, to the correct persistent volumes. Data left only in a container’s writable layer can be lost when the container is replaced. For a Compose stack, declare the volumes in your manifest. A persistent volume is not a backup: deletion, application errors or host failure can still affect it.

Keep secrets out of the image

Never bake API keys, database passwords or tokens into a Dockerfile or commit them to the repo: anyone who pulls the image or clones the repo gets them, and they persist in the layer history. Pass them as environment variables at deploy time instead. For a private repo, use a deploy key or a fine-grained, repo-scoped, read-only token, never your personal access token with full account scope.

Add a Tor mirror in the same step

Supported app deployments can add a Tor v3 .onion endpoint. Review public routes, published ports and application dependencies separately; adding Tor does not automatically remove other access paths. See how to publish a Tor .onion site for the app flow and its distinction from Tor Manager.

Only publish the port you mean to

Expose the single port your app serves. Admin panels, database ports and metrics endpoints should stay unreachable from the internet, reachable only from inside the deployment or over your own private path.

Verify a custom hostname before deployment

For a direct connection, point the hostname’s A records only at this server’s reported public IPv4 address. If you also publish AAAA, every address must match the IPv6 address reported for this server. An old or unrelated AAAA record can make the check fail even when the A record is correct. Wait for the Agent to report its address and for DNS to propagate before retrying. Managed imprezaapps.com names are assigned by the platform; do not enter another customer’s managed name as your own domain.

Use a TXT proof for a proxy or CDN

When your own proxy/CDN keeps the hostname’s public addresses elsewhere, prove control through the authenticated REST API, using an account credential permitted to manage:

  1. Request POST /v1/platform/hostname-proofs with your domain.
  2. Publish the returned txt_record.name and txt_record.value in your DNS provider. Use the exact response, not a sample value; Impreza does not edit your DNS for you.
  3. Request POST /v1/platform/hostname-proofs/verify with the same domain and returned challenge_id. Read the result and wait for verified before retrying the deployment or domain change.

A challenge expires after 15 minutes and is single-use. A successful claim is valid for 24 hours; keep the TXT record published while you use it and follow the renewed proof flow when required. A missing or mismatched record needs correction, not repeated blind deployment requests. Keep API credentials outside the chat; use the REST authentication guidance or ask support for help with this flow.

Ownership verification admits the hostname; it does not configure the proxy/CDN, issue the certificate, install the app or prove that visitors can reach it. Complete those checks separately. If you prefer a managed address for an eligible app, leave the custom domain empty and use the allocated free subdomain.

Confirm the route before sharing the app

With Agent 0.6.43, a deployment that applies public routes requires the proxy to acknowledge those routes. If applying or reloading the route fails, the operation reports failure instead of advertising a working public address. A redeploy that intentionally keeps the existing route must already have a matching published route for that app. Read the final operation and check the URL yourself; proxy acknowledgement is not proof that every app function works.

For newly rendered TLS routes using Impreza DNS, propagation checks now wait 60 seconds before the first DNS-01 check and allow up to ten minutes for propagation checks. Certificate setup can take longer than the first container start. This is not a ten-minute guarantee for total certificate issuance, and existing route fragments or routes using another DNS provider are not changed automatically.

If an older deployment is missing its route, updating the Agent alone does not recreate it. Keep the app and command identifiers and use the deployment recovery guide before repeating changes. HTTPS setup and testing an onion route remain separate checks; see the release notes for the precise routing limits.

Keep it running

After deployment, check the app URL, logs and actual behavior. Use app inspection and maintenance for supported operations; native maintenance commands depend on the app, and are not available for every custom image. If you configure a Git webhook, verify the result of each triggered build: see auto-deploy on git push.

Check a new version before moving traffic

With Agent 0.6.27 or later, eligible custom web apps can opt in to a redeploy that keeps the previous version serving while the new one starts and passes readiness checks. This is for one web service through a managed domain or onion, without a fixed host port or writable volumes; catalog apps and multi-service stacks do not qualify. Follow redeploying after readiness checks to inspect eligibility and plan the change. It is not a guarantee of uninterrupted connections.

For the route’s protection, follow Impreza Shield. Configure challenges and request limits with the app’s actual clients in mind; browser proof-of-work is not suitable for every API integration.

Prepare recovery before changing the app

Review app backups to your account’s Impreza S3 storage. Check coverage of the deployment data directory and detected named volumes; custom bind mounts, external databases and remote storage need separate review. A file copy while a database is running does not prove database consistency. Keep the deployment record and test the app-specific recovery procedure.

Moving hosts also requires a tested cutover: follow migration between compatible servers and check configuration, data, routes and external integrations before switching traffic.

Add a www alias only where supported

Agent 0.6.44 can serve a www alias for a custom domain when the platform enables it for that deployment. The server checks DNS before enabling the alias; the Agent does not add one automatically. Configure the required DNS records, request the alias through the supported platform control and verify both the main URL and its redirect.

An installed version alone is not proof that the control is available. Read the server’s capability and the operation result; an unavailable alias leaves the deployment unchanged. This is separate from buying a domain or setting an email address. Follow custom domains and aliases for current eligibility.

Start now

Spin up an offshore VPS, or let your AI assistant do the whole flow from chat with the Impreza MCP.

My Apps + Impreza MCP

One platform. Two ways to start.

Deploy and manage supported apps from My Apps or a connected AI assistant. Choose an Impreza VPS, or connect a compatible server you already administer.

New infrastructure

A VPS from Impreza

From US$9 /month

1 vCPU · 1 GB RAM · 20 GB SSD
Monthly billing

  • Choose the location and resources for your project.
  • Select the optional Impreza Agent for supported app management and AI operations.
  • Connect up to 5 external servers in total while an Impreza VPS is active.

Entry size shown. Your app may need more capacity. Backup storage and other separately billed services are extra.

Configure your VPS

Keep your current host

Your existing server

First server free

One external-server connection
No Impreza VPS or account balance required

  • Connect a compatible Linux server you administer.
  • Deploy supported catalog apps or custom applications.
  • Use My Apps or an authorized AI assistant through MCP.

The connection slot is free. Your existing hosting bill, domains and backup storage are not included.

Connect your server

App management requires the Impreza Agent to be installed and online. You choose the permissions delegated to a compatible AI assistant. Review the selected configuration and final total before purchasing.