Operating a deployment

What people running Agent Fleet on their own infrastructure want to do, one task per page. The commands are in each target’s runbook; these pages say what they decide.

Getting started

Page	What you can do
Self-hosting at a glance	Learn what it does, what you need, and what the operator is responsible for. Read it before deciding to adopt
Choose where to deploy	Choose between compose, native, AWS and Kubernetes, and compare AWS cost and egress routes

Install

Page	What you can do
Install Agent Fleet	Generate the secrets, configure sign-in, start it, sign in as the first administrator and welcome members
Choose the tenant and provisioning model	Decide how the certificate is obtained, invitation or automatic admission, how tenants are split, and each tenant’s sign-in

Day-to-day operations

Page	What you can do
Back up and restore	Run backup.sh on a schedule and restore on another host
Upgrade	Move to a new release and move workspaces onto the new image
Install into a closed network	Provide images, TLS, CLIs and diagram icons on a host that cannot reach the outside
Give every agent instructions	Have every agent read operating rules through the fleet policy
Run opencode’s shared server	Manage the server behind Terminal sessions and the opencode release
Expose it to the internet	Know what gets through when probes arrive, and narrow the entry
Tell deployments apart	Give each deployment a colour and a label
Use idle stop and force-stop	Set the auto-stop times, stop workspaces that will not stop, pause the deployment

Sign-in

Page	What you can do
Set up how people sign in	Learn what every IdP has in common, the redirect URI and where each setting lives, and check that it worked
Sign in with Google	Create a client in Google Cloud Console and put it in .env
Sign in with Microsoft Entra ID	Register an app in Entra and pin the issuer to your directory
Sign in with GitHub	Let in only members of your GitHub organisations
Sign in with another OIDC IdP	Connect Okta, Keycloak, Auth0, Cognito, GitLab and others
Approve a tenant’s own sign-in	Check, approve and stop an IdP a tenant registered

When something goes wrong

Page	What you can do
Find the cause from the symptom	Read the log and health, and narrow the cause down from the symptom table: the three constraints of driving Docker from a container, TLS, the FAQ
Cannot log in	Find out why sign-in is refused, a button is missing, or a removed person still gets in

Security

Page	What you can do
Understand the threat model and residual risks	Learn where the isolation boundary is, prepare for the remaining risks, report a vulnerability
Handle the deployment keys	Meet what AF_MASTER_KEY and AF_COOKIE_SECRET must be, add a key to a deployment without one, seal old values
Control outbound traffic	Observe workspaces’ outbound traffic and narrow it with an allowlist
Operate MCP and external-connection sign-in	Open /mcp with OAuth, decide which client hosts to trust, read what arrived in the log
Use development sign-in	Know where AUTH=dev may be used, turn the development OIDC IdP on or off
Other operational controls	Keep the preview domain, the sign-in allowlist, the audit log and the host’s cloud identity right
Revoke access and hand over super_admin	Remove people, end everybody’s sessions, change the deployment administrator

Keys

Page	What you can do
Put the keys at rest on AWS KMS	On AWS, protect what the Control Plane seals with KMS and re-seal values stored before the switch
Give each home its own key	On AWS, seal each member’s credential store under a key of its home’s own
Rotate the bridge tokens	Invalidate workspace tokens for one member or for everyone at once

ECS

Page	What you can do
Replace and stop slots	On ecs-ec2, replace outdated slots and notice and stop a slot that does not answer

Inference engines

Page	What you can do
Run inference engines on your own GPUs	choose each role’s mode, set the idle stop and the GPU instance class, and the words kept out of every picture
Take models into the inference engines	find models on Hugging Face and Civitai, take them in and enable them; let a tenant take models in
Check the inference engines’ state and history	read the running instance and the requests, and look at 14 days of uptime
Run the read-aloud engine	provide and run the VOICEVOX engine, and keep the shared pronunciation dictionary
Generate images on your own ComfyUI	Point the image engine at a ComfyUI on your network, register its models and close the routes to it
Borrow another deployment’s engines	Use the chat and image engines of an Agent Fleet on AWS from a deployment on your own host, and issue the token as the lender
Chat on a llama.cpp on your LAN	Point the chat engine at a llama-server on your network

The content of these chapters has moved to the pages above: 01 Choosing a deployment target, 02 Initial setup, 03 Running it, 04 Securing it, 05 Sign-in methods, 06 Diagnosing it, 11 The ecs-ec2 slot pool, 12 Keys at rest, 07 Inference engines and read aloud, 08 Image generation on your own ComfyUI, 09 Borrowing another deployment’s engines, 10 Chat inference on your own llama.cpp

What each target supports is in Deployment targets; who may do what is in Roles.