Skip to main content
If your app runs as Docker containers on servers you rent (Hetzner, AWS, DigitalOcean, a VPS), you pay for those servers around the clock. You also run them: capacity, images, restarts, certificates, a reverse proxy. Agent37 runs the same containers for you, one instance per container, and meters each by the minute: compute while it is up, disk alone while it is stopped or asleep. Nothing about your image changes.

​
One container, one instance

An instance is one container from your image on its own isolated computer. Your ENTRYPOINT is its main process, its disk persists, and every port it listens on has an HTTPS URL derived from its id. There is no Docker to run inside an instance: whatever you docker run today becomes its own instance, created with one API call. Three commands move a container:
The build runs on Agent37’s infrastructure and streams its log to your terminal (see Build a custom image). The create call returns once the container is up, usually within seconds. The instance URL routes to the template’s default port. Any other port is at https://{instanceId}-{port}.agent37.app with the same header. A port that must answer without a key (a webhook, an embed) gets a public port.

​
docker to Agent37

A docker-compose.yml maps the same way, service by service. Services that call each other over HTTP each become an instance; route those calls through your own server, which holds the key, or give the called service a public port with its own authentication in front. Point the app at a managed database, or run the database in the same instance as its app with its data under /home/node; your instances reach anything on the public internet.

​
Why it costs less

A rented server bills every hour it exists. Most containers on it do nothing for most of those hours: a per-user session waits for the user, a worker waits for a job, a preview waits for someone to open it. An instance created with auto_sleep: true sleeps once it has been idle for idle_timeout_seconds and wakes on the next request, usually in well under a second. Idle means no traffic through the instance’s URLs or exec, so set idle_timeout_seconds to the longest gap you expect between requests. Awake minutes bill the compute rate; asleep minutes bill disk alone. A 2 vCPU / 4 GB instance awake an hour a day costs about $0.54 per month, against $4.76 always-on. Either price includes the URL, TLS, restarts, and the API to manage it. See Billing and Auto-sleep. One team kept an 8 vCPU / 16 GB server up around the clock for up to 13 coding-session containers, whether or not anyone was in a session. As instances with auto-sleep, each session bills compute only while its user is working in it.

​
If your app launches containers for its users

Products that create a container per user, per session, or per job (a coding sandbox, a preview environment, an agent runner) carry a layer of machinery to do it. A pool of servers, an agent on each that talks to Docker, a registry, a scheduler, a watchdog, a router that maps each user to a server and port. On Agent37 that layer is the API. The plan:
  1. Publish the image you launch. Your session image, unchanged, becomes a workspace template with the port your users hit as its default_port. Each image you launch is its own template.
  2. Replace docker run with create. Where your scheduler starts a container, call POST /v1/instances with the container’s environment as env, and store the returned instance id where you kept the container id. Where it stops one, call DELETE. Put your own session id in name or metadata so you can find the instance again from your side.
  3. Point your reverse proxy at the instance URL. Wherever you forward a user to server-ip:port, forward to https://{instanceId}.agent37.app instead and add the X-Agent37-Key header with your key. WebSockets pass through, so live reload and terminals keep working. Your own domain, cookies, and login stay as they are; your proxy is still the front door.
  4. Delete the fleet. Server provisioning, the per-server agent, capacity planning, the registry, the watchdog, and the wildcard certificate have nothing left to do.

​
Make the image at home here

Most images need nothing. Two habits make the move smooth:
  • Let the entrypoint run again on the same disk. A restart, a stop followed by a start, or a wake that boots fresh runs your ENTRYPOINT again with last time’s files still on disk. Skip work that is already done: a repository that is already cloned, a migration that already ran, a directory that already exists.
  • Fetch short-lived secrets at boot. env is set when the instance is created and replayed on every start. Long-lived configuration belongs there. Fetch a credential that expires, such as a one-hour installation token, from your own server when the container starts.
Your image runs as the user it declares, root included. Bind services to 0.0.0.0, as you would for any container.

​
Hand this to your coding agent

If a coding agent is doing the move for you, give it the mental model up front: