Which Platforms Can Host Our Docker Agents When We Already Have Model API Contracts?

If your agent is already a Docker image and you already hold model API contracts, the only piece left to add is hosting, and Option 01, Compute, on Agentbox is built for exactly that. GMI pulls the image, starts the containers, isolates each session, exposes a public endpoint, and shows instance status and logs. The model layer stays yours, with your own providers and API keys. An image that already serves HTTP on a port is most of a deployment. Agentbox is in early access.

A hosting-only setup needs four things from the host: dedicated, isolated instances per session; a lifecycle you can drive through an API; secret storage for your provider keys; and a pattern for tasks that outlast a gateway timeout. Agentbox covers each of them. You point it at the image, set your secrets, map the port, and register.

What you hand to GMI and what you keep

Agentbox splits into three adoption paths. Option 01 Compute covers hosting. Option 02 Models gives you 200+ models on one API key while you run your own runtime. Option 03 combines both. An agent with its own model provider uses Option 01.

In GMI's docs, this is the pattern the "Powered by GMI Infrastructure" badge describes: the agent is hosted on dedicated GMI infrastructure and the publisher supplies the model and API.

In the registration wizard, leave the MaaS integration toggle off. That toggle injects a GMI model key into your container for GMI's own models; with it off, your agent calls your provider with the keys you supply.

What your image has to do

The register guide sets three requirements for the image:

• Serve HTTP on a known port. The default is 8080.
• Answer health checks on that port.
• Return responses within the gateway timeout. Longer jobs use the async pattern covered below.

Keep credentials out of the image and supply them as environment variables at registration.

Any public or private registry works, including Docker Hub and GitHub Container Registry. If the registry needs authentication, switch on Enable Credentials in the Infrastructure step and enter the registry username and an access token there.

Deploy it in the Register wizard

1. Basics and template. Choose GMI CE Deployment, the path where GMI hosts the container, and give the agent an internal project name.
2. Infrastructure. Paste the registry URL, such as registry.hub.docker.com/your-org/your-agent:latest. Turn on Enable Credentials for a private registry. Pick the Container tier, which gives each instance 2 vCPU, 4 GB RAM, 10 GiB of ephemeral storage, and 30 GiB of data storage, and keep MaaS integration off.
3. Networking. A public IP is allocated for you. The default mapping sends HTTPS/2 on external port 443 to internal port 8080, named web. Change the internal port if your server listens elsewhere, or add mappings for more ports.
4. Env variables. Add your configuration. Use TEXT for non-sensitive values such as log levels. Use SECRET for your model provider's API key and any other credential.
5. Review and register. Check the summary and register. Agentbox stores the template; registering does not start an instance.
6. Launch and test. Launch an instance from the Monitor tab or the API. When it reaches Running, it has its own public URL. Send a sample request to that URL to test latency, output, and error handling.

Set the internal port in the default mapping to the port your server listens on. Source: GMI Cloud docs.

Enable Credentials adds a registry username and access token so Agentbox can pull from a private registry. Source: GMI Cloud docs.

SECRET is the right home for your provider key, because the UI never shows a saved secret again. Variables GMI injects are locked and cannot be overridden.

Agentbox pulls the image from your registry and builds the container each time an instance is provisioned. Iterate by registering again; the registration endpoint stays stable across updates. Your registration is private to you as a Draft, and publishing to the Marketplace is an optional flow of its own in the docs.

Choose the run shape: ephemeral, long-running, or always-on

The Agentbox page describes three workload shapes.

Oqoqo, an Agentbox customer, is an example on the ephemeral end. It evaluates agents, MCPs, SDKs, APIs, and CLIs, and runs those evaluations on Agentbox in clean, throwaway environments built from its own Docker images and memory profiles, with no sandbox infrastructure to build or maintain.

You control instance lifetime through the Agentbox API. The Integration tab of your agent's dashboard shows the template ID and a four-call workflow using your GMI API token: provision an instance, list the tasks, poll until the status is running, and terminate when the session ends. Each instance's logs are one click away in the Monitor tab.

Compute is metered per second from the moment an instance reaches Running until you terminate it, so for ephemeral and per-session agents, delete the instance when the session ends with the terminate call above. For always-on agents, you keep one instance running.

Handle long agent tasks

Agent tasks can take anywhere from 30 seconds to several minutes, and a caller that holds one open connection past the gateway window gets a 504. The long-running requests guide separates acknowledging the request from delivering the result:

1. Accept the request and return a 202 with a job_id immediately.
2. Run the work in a background task.
3. Expose a status endpoint that callers poll every 3 to 5 seconds until the result is ready.

Containers are stateless, so a restart wipes anything held in memory. Keep job state in Redis or a database and inject its credentials as SECRET variables. If your own provider call is the slow part, this pattern also keeps your agent from tying up a connection while it waits on the model.

What billing looks like

GMI's invoice carries container compute from the time an instance reaches Running until it is terminated. GMI model-token usage is metered separately and applies only if your agent calls GMI models. Your provider's charges stay on its own invoice under your contract.

When another Agentbox option fits better

If you later want to consolidate providers, Option 03 adds GMI's models to the same deployment: turn the MaaS integration on, select models, and GMI injects the key and base URL. Option 02 is the reverse case, where you keep your own runtime and only want model access.

FAQ

Our team builds images on Apple Silicon Macs. Which architecture should the image target?

Build for linux/amd64, because Agentbox compute is x86_64, the same platform GMI's Agentbox guide builds for. On an Apple Silicon Mac, docker buildx build --platform linux/amd64 --push -t <your-registry>/<image> . builds for that target and pushes to your registry, and you then register that image URL.

The instance is Running but requests to its URL fail. How do we tell a gateway timeout from a networking problem?

A 504 means the gateway did not get a timely response from upstream. If the endpoint cannot be reached at all, check that ingress is enabled and networking is configured for the deployment, starting with the Networking step: the internal port in the mapping must match the port your server listens on (the default mapping sends 443 to 8080), and the server must be listening. The 202 and job_id pattern only helps requests that reach the agent.

Register the agent you run today as a private deployment

Register your current image, store your own provider key as a SECRET variable, test the instance's public endpoint, and watch the instance in the Monitor tab. The Agentbox overview covers the Marketplace badges, and the GMI console is where registration begins.