Remote agents,
under your control.

The standard setup takes four steps. Your first account becomes the owner of a new organization; every resource created after that belongs to the same organization.

1. Create your account

   Register in the Avenbay console with an organization name, email, and a password of at least 12 characters.

2. Verify your email

   Open the verification link sent by Avenbay, then sign in. Verification links are single-use and valid for 24 hours.

3. Connect a host

   In Hosts → Add host, name the machine and run the one-time enrollment command on it.

4. Start a session

   Choose the connected host, project, working directory, and agent. Open its terminal or send a task without opening SSH.

Each account belongs to exactly one organization. Organization membership comes from the authenticated server session—it is never selected or supplied by a browser API request.

Account lifecycle

• Invitations are single-use and expire after seven days.
• Password-reset links are single-use and expire after one hour.
• Changing a password revokes all existing login sessions.
• Authentication uses an opaque HTTP-only cookie; JavaScript cannot read its value.

The worker is a small service installed next to your repositories and agent binaries. It establishes an authenticated outbound WebSocket connection to Avenbay and does not open a listener.

1. Generate an enrollment command

Open Hosts, select Add host, and enter a recognizable machine name. Avenbay displays a 15-minute, single-use command:

fleet-worker enroll --url https://avenbay.com --token <single-use-token>

2. Configure the worker service

The enrollment exchange prints a host ID and 90-day worker credential. Store both in the service environment, never in shell history or a command argument.

FLEET_CONTROL_URL=wss://avenbay.com/v1/worker/connect
FLEET_HOST_ID=host_replace_me
FLEET_WORKER_TOKEN=replace_with_enrollment_secret
FLEET_STATE_PATH=/var/lib/fleet/state.db
FLEET_ALLOWED_EXECUTABLES=codex,claude
FLEET_ALLOWED_ROOTS=/srv/repositories

3. Start and verify

Run the worker as a dedicated, non-root Unix account with access only to the repositories it should manage. The host will appear as online after its WSS connection is accepted.

An adapter translates Avenbay’s common session operations into the command-line behavior of a specific coding agent. The worker starts the selected executable inside its private tmux server, delivers tasks, and reports lifecycle state to the control plane.

Adapters do not grant the control plane arbitrary shell execution. Workers accept typed operations against Avenbay session IDs and enforce the executable and filesystem policy locally.

A session belongs to one organization, host, project, and owner. Its process runs in the worker’s private tmux server, so closing the browser does not stop the agent.

Coordination tasks let one running agent session delegate a bounded piece of work to another running session in the same organization. Agents create and update tasks with the scoped fleet-session CLI; operators monitor every handoff from the console’s Tasks page.

Prerequisites

• Use a worker release that advertises the session_cli capability and includes the fleet-session binary.
• Create new sessions after that worker connects. Existing sessions must be recreated to receive their scoped session environment.
• Keep both the source and target sessions running. A session cannot send a coordination task to itself.

Delegate work from an agent session

Run these commands inside a Fleet-managed terminal. First discover the other running sessions in your organization:

fleet-session whoami
fleet-session peers

Choose a target session ID from peers, then create the handoff:

fleet-session send \
  --to sess_target \
  --task "Review the authentication changes and report any regressions"

The command returns JSON containing the new ctask_… ID. Avenbay records the task, attempts to deliver a notification into the target session, and exposes it immediately in the Tasks dashboard.

Work the target inbox

The target agent receives the task instruction together with acknowledgement commands. It can also inspect its inbox explicitly:

fleet-session inbox
fleet-session show ctask_123
fleet-session accept ctask_123
fleet-session progress ctask_123 --message "Tests are running"
fleet-session complete ctask_123 --message "Review complete; no regressions found"

For a large result, use --result-file PATH with progress, complete, or fail. Result files are limited to 120 KiB.

Follow up from the source session

fleet-session status ctask_123
fleet-session wait ctask_123 --timeout 20m
fleet-session cancel ctask_123

wait polls until the task is completed, failed, or cancelled. Cancelling stops Fleet coordination but does not guarantee that a target agent which already began work has stopped; interrupt that session manually when necessary.

Delegate a child task

A target session can delegate part of an accepted task to another running session and preserve the relationship:

fleet-session send \
  --to sess_specialist \
  --task "Check the database migration for rollback safety" \
  --parent ctask_123

The parent must target the session creating the child. Delegation depth is limited to three levels to keep coordination bounded and understandable.

Use the Tasks dashboard

Task states

Run the control plane and web console behind TLS, use PostgreSQL for persistent state, and configure Mailjet Send API v3.1 before enabling public signup.

AVENBAY_ORIGIN=https://avenbay.com
AVENBAY_APP_URL=https://app.avenbay.com
FLEET_ALLOWED_ORIGINS=https://avenbay.com
FLEET_SECURE_COOKIES=true
FLEET_PUBLIC_SIGNUP=true
FLEET_MAILJET_API_KEY=use-a-secret-manager
FLEET_MAILJET_SECRET_KEY=use-a-secret-manager
FLEET_MAILJET_FROM=Avenbay <[email protected]>

Production checklist

• Terminate TLS 1.2+ and preserve WebSocket upgrades with a long idle timeout.
• Set exact allowed origins and trusted proxy CIDRs.
• Run database migrations from one instance and test PostgreSQL restoration.
• Monitor Mailjet delivery, readiness, worker disconnects, HTTP 5xx, and pool saturation.
• Use a single fleet-server replica; live worker and terminal routes are currently held in process.
• Apply registration and connection rate limits at the edge.