Deployment and hosting

Two questions decide whether a platform is something you can actually operate: where does it run, and what happens to the work in progress when you deploy a new version. Disco Parrot answers both with very few moving parts. The platform is one deployable unit running on Azure Container Apps, your agents' sandboxes run where you choose, on managed compute or on your own Kubernetes or Docker, and a deploy does not drop the work in flight. This page is how that holds together.

It is the operations view. The hands-on setup of a host is on sandbox hosts, the network shape is on network and connectivity, and the overall shape of the system is on system overview. Here the question is how it deploys and where the compute lives.

One unit to deploy

Disco Parrot builds to a single container image that runs as a single Node process, and that one process serves both halves of the product: the API, and the built single-page app as static files. There is no separate front-end deployment, no API gateway to stand up beside it, no worker fleet to version in step. You ship one image, it runs one process, and that process is the whole platform. System overview is the fuller account of why the system is shaped this way; the deployment consequence is that there is very little to deploy.

From a build to a live revision

A release runs the same short path every time. One build command compiles the front end and the server into an app bundle and a server bundle, both go into a single container image, and that image rolls onto Azure Container Apps as a new revision behind the readiness check. The orchestrator holds traffic on the running revision until the new one answers ready on its /__ready endpoint, then moves traffic across and drains the old one. There is no front-end to publish on its own, no schema-migration step to sequence against the deploy because the data layer is schemaless and grows its containers on first use, and no second artifact to keep in version with the first. One artifact, one gate.

Local development is the same platform

Development runs the same platform, not a stand-in for it. The dev server mounts the exact application the production process serves, so an API call you make in development is handled by production's own code rather than a mock that drifts from it. Sandboxes work the same way, including a Local Docker host you run on your own machine, so the path you exercise while building is the path that ships. The one accommodation development makes is for storage: a local run can point at a database emulator with a key, where production authenticates as an identity and holds no key at all. What passed in development is what the image carries.

The platform runs on Azure Container Apps

The platform itself runs as a container app on Azure Container Apps, in a network-backed environment, with health probes the platform answers on a readiness endpoint so the orchestrator only sends traffic to an instance that is ready. It runs as a single instance, and that is the right shape for what it does: the live event stream every browser holds and the scheduled background work both want one obvious home, so the platform keeps one. The scheduled work is pinned to that instance, so a recurring job fires once and only once, with no second copy of the platform racing the first to run the same job.

The result for an operator is a control plane with a small surface: one image, one app, one place the schedule runs, behind health checks that gate traffic. Operating it stays quiet: a restart is a drain to a ready replacement behind those same probes rather than a hand-off you manage, and because the schedule has exactly one home there is one place recurring jobs fire and one set of logs to read them in.

Where your sandboxes run

An agent's work happens in a per-run sandbox, and the sandbox does not have to run on the platform's compute. There are three places it can run, behind one provider abstraction so the rest of the platform does not change when you change where the work happens:

• Managed compute. By default, with nothing for you to register, a sandbox runs on the platform's own Azure Container Apps compute. This is the zero-setup option: a profile that names no host lands here.
• Your own Kubernetes. You register a Kubernetes host, and an operator you run in your cluster drives the sandbox pods. The work runs entirely on your infrastructure.
• Your own Docker. You register a Local Docker host, and an operator on your own machine or server runs the sandbox containers there.

The two bring-your-own options are the ones you register; managed is the fallback that needs no registration at all. A profile points at a host, the resolver picks the matching provider, and if a profile names no host the resolver lands on managed. Adding a new kind of host is a new provider behind the same interface, not a change to the code that launches agents. Sandbox hosts is the setup guide for each.

The bundle a host applies

Bringing your own host is not a fleet of services to stand up. You run one operator in your cluster or on your machine, and it dials out to the platform over a single channel rather than opening a port the platform reaches in through. When you register a host, the platform hands you a pre-filled bundle to apply: a multi-document Kubernetes manifest you kubectl apply for a cluster, or a Docker Compose file you bring up for Local Docker. The bundle carries what the operator needs to identify itself and find the platform, and nothing inbound. The operator opens the connection, receives work, and drives sandboxes on your side. The hands-on setup for each host is on sandbox hosts, and the outbound channel it runs on is on network and connectivity.

Running on your compute, or ours

Where a sandbox runs decides one thing directly: managed compute is metered, and your own compute is not. When a sandbox runs on the platform's managed Azure compute, its time counts against your plan's compute usage, because the platform is paying for that capacity. When it runs on your own Kubernetes or Docker, the platform meters nothing, because you are already paying your cloud or your hardware for it directly. Bringing your own host moves both the compute and its cost onto your side of the line, which is exactly why a team with spare capacity or a strict data-residency rule chooses it. The choice is yours to make per profile, and the platform behaves the same either way.

A deploy does not drop work in flight

On a release day, the property that matters is that the work in progress rides through it, and it holds whether the sandbox runs on your compute or on ours.

When a sandbox runs on your own host, the work runs on your compute, and a platform deploy does not reach into it. If the operator's connection to the platform blips during a rollout, the running pod or container keeps running; nothing cleans it up. When the operator reconnects, it reconciles the live sandbox in place, repairing the channel rather than tearing the work down and starting over. A flow that was mid-step on your cluster is still mid-step when the platform comes back.

When a sandbox runs on managed compute, the run's state lives in the platform's store, not in the memory of one platform instance. The platform rolls a new revision the ordinary way, draining to a ready instance behind the health checks, and the new instance picks the run back up from the stored state. A streaming chat turn rejoins from its cursor, and a turn whose underlying session was interrupted is continued from the conversation the platform kept, so the agent's context survives the deploy rather than resetting. Either way, the work you had in flight is still there when the new version is live.

How a configuration change reaches a running sandbox

A running sandbox is reused across a person's turns as long as the things that define it have not changed. When one of them does, the profile it runs, the template, the host it targets, the image tag, or its runtime identity, the platform recreates the sandbox rather than carrying a stale one forward: it tears the old one down and launches a fresh one on the new inputs. That is how a profile edit or a new image actually reaches the work, cleanly, on the next run, rather than half-applied to a container built against the old configuration. A change to how the agent runs takes effect by giving the next run a sandbox built to match.

What each kind of host can do

The three hosts are not identical in what they offer, and the differences follow from where they run.

• Managed compute carries the richest lifecycle, because the platform owns it: it can keep a warm pool of ready sandboxes so a run starts fast, and it can pause an idle sandbox and resume it rather than rebuild it, scaling it down while no one is working in it so a long-lived session stays responsive without holding compute, or its meter, the whole time.
• Your own Docker can keep a warm pool too, and can prepare workspace volumes ahead of a run.
• Your own Kubernetes runs sandboxes on a create-and-destroy model, fresh each time, which is the simplest contract to reason about on a cluster you operate.

None of this changes what an agent can do inside a sandbox; it changes how quickly one is ready and whether it is reused or rebuilt. You pick the host for where you want the work to run, and the lifecycle that comes with it is part of that choice.

How the platform gets its secrets at deploy

The platform reaches its own dependencies the same no-standing-key way the rest of it runs on. It authenticates to its data stores and its vault as a managed identity, with no database account key in production, so a deploy ships no long-lived store credential. Its configuration secrets are loaded at startup from a per-workspace vault that is provisioned lazily and read through that same managed identity, with environment values able to override where a deployment needs them to. There is no secret baked into the image and no key for an operator to rotate by hand.

Your own secrets sit the same way. A workspace's connected-tool and runtime credentials live in that per-workspace vault rather than in the image or the platform's environment, so deploying a new revision never moves or re-bakes them. The platform and its managed compute run in a single Azure region, and a requirement to pin data to a particular geography is part of your agreement rather than a setting on a page. The deeper account of keys, vaults, encryption, and residency is on encryption and data handling and identity and cloud access.

A release day, with work in flight

When the team ships a platform update on a Thursday afternoon, two runs are in progress. Priya's flow is mid-step on her team's own Kubernetes cluster, and Sarah's chat is streaming an agent's reply on managed compute. The rollout begins. Priya's pod keeps running on her cluster the whole time, because the platform does not reach into it; when the platform's connection re-establishes, the operator reconciles the sandbox in place and her flow is exactly where it was. Sarah's browser loses the stream for a moment as traffic moves to the new instance, then rejoins her turn from its cursor and the reply keeps filling in. Neither of them files a ticket, because neither of them noticed. The deploy was one image replacing another, and the work in flight rode through it.

Why deployment and hosting work this way

The expensive way to run an agent platform is to make every release a risk to the work in progress and to force every customer onto your compute. Disco Parrot is built to avoid both. A release is one image, so there is little to operate and a single place the schedule runs. The run's state lives in the store rather than one instance's memory, so a rollout drains and resumes your work rather than dropping it. And the sandbox sits behind a provider abstraction, so you run the work on the platform's compute for zero setup or on your own Kubernetes or Docker for control and cost, with the platform behaving the same either way. The deployment story is meant to be uneventful, which on a release day is the only story worth having.

For a developer, the model is that the same application runs in development and production, mounted as middleware in dev and standalone in prod, so what you tested is what ships. It builds by one command into an app bundle and a server bundle that travel in one image. Where a sandbox runs is a provider behind one interface; adding a host kind is a new provider, not surgery on the launch path.

For a platform engineer, the operational facts are a single-instance control plane on Azure Container Apps with health-gated traffic and a scheduler pinned to that instance, sandboxes that run on managed compute or a registered Kubernetes or Docker operator, run state in the store so a rollout resumes rather than drops, and sandbox recreation on drift of profile, template, host, image, or identity. Managed compute supports warm pools and idle pause-and-resume; operator hosts create and destroy.

For an enterprise reviewer, the choice to check is where the compute and its cost sit: managed compute is the platform's and is metered, while a registered Kubernetes or Docker host runs the work entirely on your infrastructure and is not. A platform deploy does not reach into a sandbox running on your host; the running container stays up and is reconciled in place on reconnect.

For a prospect, the assurance is that running Disco Parrot does not commit you to a fleet of services or to a single place your agents can run. It is one unit to deploy, it runs your agents on your own cloud if you want it to, and shipping a new version of the platform does not interrupt the work your team has in flight.