Enterprise Deployments

AFK supports deploying the daemon on shared company infrastructure so teams can work with agents while keeping repository access and command execution inside the corporate network. This page covers shared-daemon setup, operational guidance, and deployment options for Enterprise customers.

Deployment models

The standard AFK setup runs one daemon per engineer on their own machine. Enterprise customers can add or switch to a shared daemon on company infrastructure for stronger data locality and centralised administration.

Shared daemon setup

1. Create an organisation API key

1. Sign in to AFK and switch to your organisation context.
2. Open Account → API Keys and create a new key. Give it a descriptive label such as build-server-01.
3. Copy the token immediately — it is displayed only once. This key registers the daemon under your organisation.

2. Install the daemon on your server

AFK distributes native Linux binaries (amd64 and arm64). Use the install script or download the latest release manually.

# Option A: install script with the org token
curl -fsSL https://afk.mooglest.com/install.sh | bash -s -- <org_daemon_token>

# Option B: manual download (no token in the command)
VERSION="$(curl -fsSL https://git.mooglest.com/api/v1/repos/mooglest/public/releases/latest \
  | sed -nE 's/.*"tag_name"[[:space:]]*:[[:space:]]*"([^"]+)".*/\1/p')"
ARCH="$(uname -m)"
case "$ARCH" in
  x86_64)  ASSET="afk-linux-amd64.tar.gz" ;;
  aarch64) ASSET="afk-linux-arm64.tar.gz" ;;
  *)       echo "Unsupported arch: $ARCH" && exit 1 ;;
esac

curl -fsSL "https://git.mooglest.com/mooglest/public/releases/download/${VERSION}/${ASSET}" \
  | sudo tar -xz -C /usr/local/bin afk
sudo chmod +x /usr/local/bin/afk

3. Configure the daemon

Create a config file at ~/.afk/config (use the dedicated service user's home directory if you are creating one):

api_key=afk_org_your_token_here
server=wss://afk-server.mooglest.com
home=/home/afk
name=build-server-01

4. Set up a systemd service

A dedicated service user is recommended for shared daemons. Create /etc/systemd/system/afk.service:

[Unit]
Description=AFK Daemon
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
User=afk
Group=afk
ExecStart=/usr/local/bin/afk daemon
Restart=on-failure
RestartSec=5
WorkingDirectory=/home/afk
Environment=HOME=/home/afk

[Install]
WantedBy=multi-user.target

# Create the service user
sudo useradd --system --shell /usr/sbin/nologin --home /home/afk --create-home afk

# Set up the config
sudo mkdir -p /home/afk/.afk
sudo cp ~/.afk/config /home/afk/.afk/config
sudo chown -R afk:afk /home/afk/.afk

# Start the service
sudo systemctl daemon-reload
sudo systemctl enable --now afk

# Check it is running
sudo systemctl status afk
sudo journalctl -u afk -f

5. Verify

After starting the service, open the AFK browser app and switch to your organisation context. The daemon should appear in the connected daemons list within a few seconds with a green status indicator.

Granting access to project directories

The daemon can work on any directory the service user has read access to. Grant access to the repositories your team needs:

# Option 1: make the daemon user the owner
sudo chown -R afk:afk /srv/projects/frontend

# Option 2: use ACLs for granular control
sudo setfacl -R -m u:afk:rx /srv/projects/backend

# Option 3: add the daemon user to a shared group
sudo groupadd afk-projects
sudo usermod -a -G afk-projects afk
sudo chgrp -R afk-projects /srv/projects/shared
sudo chmod -R g+rx /srv/projects/shared

The daemon discovers available projects from the filesystem. Any directory the service user can read is available as a spawn target for org members.

Personal daemons alongside shared daemons

An organisation can use both personal daemons and shared daemons at the same time. This is common when some engineers prefer to run locally while others use a central server, or when different projects live in different environments.

Org admins control whether members can use personal daemons for org sessions through Account → Members:

• Allow personal daemons — when enabled, members see their own personal daemons alongside org daemons when working in org context.
• Allow automations on personal daemons — a separate opt-in for running scheduled or webhook-triggered work on personal machines.

Sessions launched through a personal daemon remain org-owned and attributed to the member who initiated them. Other members never see another member's personal daemon or its metadata.

Corporate network integration

The shared daemon needs outbound HTTPS and secure WebSocket access to the AFK hub and the model providers your team uses. No inbound ports are required.

Custom CA certificates

If your network uses a company Certificate Authority for TLS inspection, VPN services, or internal endpoints, add the CA bundle path to the daemon config:

# In ~/.afk/config
ca_cert_file=/etc/ssl/certs/company-ca.pem

Alternatively, set the AFK_CA_CERT_FILE or SSL_CERT_FILE environment variable. AFK adds these certificates to the normal JVM and process trust roots, including spawned MCP servers, without replacing public CAs or disabling TLS or hostname verification. Restart the daemon after changing this setting.

Proxy configuration

If outbound traffic must go through an HTTP proxy, add proxy settings to the systemd service environment:

Environment=JAVA_TOOL_OPTIONS=-Dhttp.proxyHost=proxy.internal -Dhttp.proxyPort=3128 -Dhttps.proxyHost=proxy.internal -Dhttps.proxyPort=3128

Resource management

Use operating-system controls to bound the daemon process and prevent resource exhaustion:

# Apply memory, CPU, and task limits via systemd
sudo systemctl set-property afk.service MemoryMax=32G
sudo systemctl set-property afk.service CPUQuota=800%
sudo systemctl set-property afk.service TasksMax=512

# Verify
sudo systemctl show afk | grep -E 'MemoryMax|CPUQuota|TasksMax'

Docker-backed sessions also accept per-session CPU and memory limits configured at spawn time.

Operations

Upgrading

# Using the install script (recommended)
curl -fsSL https://afk.mooglest.com/install.sh | bash -s -- <org_daemon_token>
sudo systemctl restart afk

The AFK browser app also offers an in-app update action for connected daemons. When sessions are running, AFK prompts for confirmation before stopping them for the update.

Rotating daemon keys

1. Create a new key in Account → API Keys while in org context.
2. Update api_key in the daemon config file.
3. Restart the daemon.
4. Verify the daemon reconnects.
5. Revoke the old key.

Monitoring

# Service status
sudo systemctl status afk

# Recent logs
sudo journalctl -u afk -n 50

# Follow live
sudo journalctl -u afk -f

Session ownership and attribution

All sessions launched through a shared daemon are owned by the organisation. The real member who initiated each session is recorded and visible in the dashboard and session history. This gives teams clear attribution for audit and operational follow-up.

Dedicated control plane

For organisations that need the AFK hub itself to run inside their network, a dedicated control-plane deployment is available as a custom Enterprise arrangement. This includes hub deployment, database hosting, network and TLS configuration, identity provider integration, and operational runbooks.

Contact afk@mooglest.com to discuss dedicated deployment requirements.