Arcade Deploy on your own cluster (Helm)

This page is for platform operators who run Arcade with the Helm chart and want developers to ship custom MCP servers into that installation with arcade deploy. Once you turn deployments on, the Arcade Engine runs each deployed server as a workload in your own cluster. Bundles go to an object store you own, and runner images come from a registry you choose.

How it works

• A developer runs arcade deploy against your installation. The Arcade Engine publishes the server’s bundle to your artifact store (S3-compatible, GCS, or Azure Blob).
• The Arcade Engine creates the server in the workers namespace (arcade-workers by default). Each deployed server runs as a Kubernetes Deployment of the runner image (arcadedev/runner), one pod by default, and the pod fetches its bundle from the artifact store.
• Every deployed server gets its own NetworkPolicy. It accepts traffic only from the Arcade Engine. Outbound, it reaches the public internet and cluster DNS, but not private address ranges, link-local addresses (including cloud metadata), or the cluster ranges you list, unless you allowlist a range.
• The deployment budget sizes the workers namespace’s quota, which limits how many deployed servers can run at once.

The Arcade Engine’s service account gets a namespaced Role in the workers namespace. That Role covers Deployments, Services, Secrets, ServiceAccounts, NetworkPolicies, ResourceQuotas, Leases, read access to pods and pod logs, and read access to pod metrics. Developers never need cluster access.

Prerequisites

• A working Arcade installation from the Helm chart, with gateway.hostname, ingress.hostname, or deployments.domain set
• A bucket in an S3-compatible store, Google Cloud Storage, or Azure Blob Storage for release bundles
• Credentials for that bucket that the Arcade Engine can pick up from its environment. The Arcade Engine reads them from the ambient cloud credential chain, never from the bucket URL and never from a deploy request.
• Access from your cluster to the runner image, either arcadedev/runner on Docker Hub or a copy in your own registry
• A CNI plugin that enforces Kubernetes NetworkPolicies, so the per-server isolation takes effect

Enable deployments

deployments:
  enabled: true
  artifacts:
    # s3://, gs:// or azblob://
    url: s3://arcade-bundles?region=us-east-1

helm upgrade arcade \
  oci://public.ecr.aws/s5i6x9d1/charts/arcade \
  --namespace arcade \
  -f values.yaml

Configuration

All settings live under deployments.* in the chart values. Leave a value at its default unless you need to change it.

Core settings

Artifact store

The deployed server’s pod doesn’t hold store credentials. The Arcade Engine gives the pod a presigned download URL for its bundle when the store can sign one:

A signing failure doesn’t fail the deploy.

Runner image and registry

For a private mirror, push arcadedev/runner to your registry and point the chart at it:

deployments:
  registry:
    server: registry.example.internal
    imagePullSecrets:
      - my-registry-pull-secret

Sizing

Every deployed server gets the same size.

With the chart, each pod’s requests equal its limits, so pods run in the Guaranteed QoS class. Each pod also has a fixed ephemeral-storage request and limit of 6Gi, which covers a 5Gi volume for the bundle and its virtual environment.

Resource requests and ephemeral storage

The Arcade Engine reads these settings from deployments.kubernetes.instance in its own configuration:

deployments:
  kubernetes:
    instance:
      cpu_request: 0.1
      memory_request: 256
      ephemeral_storage_request: 512Mi
      cpu_limit: 1
      memory_limit: 512
      ephemeral_storage_limit: 6Gi

• A request below its limit puts the pod in the Burstable QoS class. Under node pressure, the kubelet evicts Burstable pods before Guaranteed pods.
• The Arcade Engine refuses to start when a request exceeds its limit, a request is negative, or an ephemeral-storage value isn’t a Kubernetes quantity.
• Keep ephemeral_storage_limit at 6Gi or higher. The bundle, temporary, and home volumes add up to 6Gi.
• The Arcade Engine sizes the namespace quota from limits, not requests.

Workers namespace

To use a namespace you manage yourself, set deployments.createNamespace: false. The chart then adds no default-deny NetworkPolicy, unless you also set deployments.network.defaultDenyExistingNamespace: true. Only do that when the namespace holds nothing but deployed servers.

The reconciler also maintains its own quota, arcade-deployments-budget. It allows budget + 1 pods (one spare for a rollout), and sizes CPU and memory as that pod count times the per-server limits.

Network

external DNS mode also needs a bundle endpoint the pod can reach without cluster DNS. Existing deployed servers pick up a DNS mode change only after a redeploy.

Deploy a server

Developers use the same workflow as on Arcade Cloud. They sign in to your installation once, then deploy from the project directory:

arcade login --url https://arcade.example.com
arcade deploy -e src/my_server/server.py

arcade login --url saves a context for your installation, and arcade deploy targets the active context. See Arcade Deploy for the full developer guide and the CLI cheat sheet for every flag.

• Deploy MCP servers built with the Arcade MCP framework for Python. The Arcade Engine refuses a bundle without a Python project definition or with a missing entrypoint.
• The Arcade Engine refuses a changed redeploy while the previous one is still rolling out.
• The Arcade Engine also refuses a bundle over the installation’s size limit, and discards a virtual environment that the bundle ships.
• A redeploy that changes the server’s code or secrets replaces the release under the same name and gateway URL. A redeploy of a running release that changes nothing is a no-op. Deploying again after a failed release rolls it out again, even if nothing changed.

Check status and logs

Dashboard and CLI

The Servers page in the dashboard lists deployed servers and their status. A running server whose instance keeps crashing shows as Degraded. A removed server disappears from the list.

From the CLI:

arcade server list
arcade server get <name>
arcade server logs <name> -f

Logs cover the current release. After a crash, they also include the immediately previous instance. Arcade doesn’t keep logs beyond that, so ship pod logs to your own logging stack if you need them longer.

kubectl

Deployed servers are ordinary Kubernetes objects in the workers namespace, so your existing tooling works:

kubectl -n arcade-workers get deployments,pods,services
kubectl -n arcade-workers get networkpolicies -l app.kubernetes.io/managed-by=arcade-engine
kubectl -n arcade-workers get resourcequota

Upgrades

Upgrade the chart with helm upgrade as described in Self-host with Helm. Keep these points in mind:

• Runner image. With deployments.image.tag empty, the runner tag follows the chart’s appVersion. Pin deployments.image.tag to control which runner tag the Arcade Engine configures.
• Private registry. Mirror the new runner tag into your registry before you upgrade.
• Namespace. With deployments.createNamespace: true, Helm keeps the workers namespace and its default-deny NetworkPolicy on uninstall, so deployed servers’ objects aren’t deleted with the release.

Troubleshooting

Next steps

• Deploy an MCP server with Arcade Deploy
• Create an MCP Gateway to give clients access to deployed servers’ tools
• Platform architecture