Skip to main content

​
About self-hosted daemons

Self-hosted daemons are ideal for teams that want Cosmos agents to run on your own infrastructure. You can run a single daemon to quickly use your personal setup to work with Cosmos, or deploy a daemon pool to provide a group of workers to Cosmos to distribute sessions to. Daemons have access to the host machine’s CPU, disk, and network; agents execute tools and make edits on the host machine but still make all LLM calls to Augment’s external services. You can use daemon pools to group multiple separate machines into a single environment. Cosmos routes sessions to eligible daemons based on workspace requirements and current load, without requiring the user to select a specific machine.

​
Using daemons

Each host must run the daemon process included with Auggie CLI.

​
Install Auggie CLI

Install the latest Auggie CLI daemon release on each host. You need npm available on the host:
Confirm that Auggie reports a 1.x version:

​
Authenticate Auggie CLI

Log in to your Augment account. Your authentication is persisted on the host:
You can also use other available authentication methods to provide credentials.

​
Start the daemon

Start the daemon from the workspace you want it to use:
When attached to a terminal, the daemon displays a dashboard with its connection status, configured workspaces, and running sessions. Press Ctrl+C to stop it cleanly.

​
Keep the daemon up to date

The daemon does not install updates while it is running. Periodically upgrade Auggie, then restart the daemon:

​
Configuration

For repeatable settings, use daemon configuration files. Auggie automatically discovers global, project, local project, and managed daemon-config.json files. You can override file settings for one launch with command-line flags. Run auggie daemon --help for the complete command-line reference.

​
Workspaces and Isolation

Choose which repositories the daemon exposes and whether sessions use shared checkouts or isolated Git worktrees. See Workspaces and Isolation for repository discovery, mixed workspace layouts, requirements, and worktree behavior.

​
Disconnecting

You can disconnect the daemon at any time with Ctrl+C or by shutting down the host machine. Messages sent while the daemon is disconnected remain queued until it reconnects. The session expects the reconnected daemon to have the same filesystem state. Use isolated Git worktrees to reduce errors when sessions reconnect to a changed workspace.

​
Networking

Daemons need outbound access to Augment services to complete inference requests. See Network configuration for the required domain allowlist.

​
Migrate from Auggie 0.x

Auggie 1.x uses the rebuilt agent harness. If a host still runs Auggie 0.x, use an identity-preserving cutover to retain the daemon identity, workspace changes, worktrees, and recoverable sessions.
  1. Let active sessions finish their current turns.
  2. Record the daemon’s canonical workspace path and repeatable launch options.
  3. Stop the existing daemon cleanly with Ctrl+C.
  4. Install Auggie 1.x:
  1. Start the daemon from the same canonical workspace path with the recorded launch options, using the same Augment account and tenant:
  1. Confirm that the expected daemon, workspaces, pool or Space, and connection status appear in Cosmos.
  2. Start a test session and verify messages, tool execution, diff review, terminal access, and local changes.
  3. Send a follow-up message to an idle session created before the upgrade to verify conversation recovery and workspace preservation.
Do not pass --new-vm-id during the migration. Keep ~/.augment/daemon and existing daemon worktrees in place, and never run Auggie 0.x and 1.x concurrently with the same daemon identity.
Optional: generate a configuration file. After installing Auggie 1.x, you can convert the recorded launch options instead of continuing to pass them on every launch. Preview the generated JSON with --config-print:
If the output is correct, write it to your preferred scope. This example uses the local project scope for host-specific settings:
Both commands exit without starting the daemon. If you write the configuration, omit <your-repeatable-flags> when starting the daemon in step 5.--config-write replaces the entire destination file after confirmation; it does not merge with existing configuration. If the destination already contains settings you need, use --config-print and merge the generated JSON manually. See Generate Configuration from Flags.
The cutover preserves durable state; it does not hand off a running process. Existing shared-workspace changes and isolated worktrees remain available, and eligible idle sessions can recover their conversation. In-flight model calls, tool executions, shells, terminals, child processes, and other in-memory state are interrupted rather than transferred.

​
Next steps