Evaluate SodaOS
Operate a factory

Run AI coding agents on a dedicated server

Install SodaOS, establish private access and prepare a bounded first repository for a self-hosted AI software factory on an x86-64 server or VM.

On this page

This guide is for the person operating the machine and the repository maintainer who will authorize its work. SodaOS provides the host and integrated development infrastructure; you supply the machine, network, provider access, repository policy and backup plan.

Prepare the installation

Choose a compatible x86-64 server, mini PC, workstation or VM with console access and a destination disk whose contents can be erased. Keep independent backups of existing data. Use a private network reachable from the setup client and select a Project subnet that does not overlap LAN or VPN routes.

Size CPU, memory and storage for the actual builds, tests, retained Projects and concurrent agents. The ISO size is a download size, not the installed capacity requirement. A GPU is not a substitute for an authorized external coding-provider connection. If a VM is used, a guest NAT address alone does not establish access from other computers.

Install and verify access

  1. Open Download, choose the ISO and verify the selected release. Keep its notes and artifact identity with the installation record.
  2. Write the ISO to the intended USB device or attach it as VM optical media. Keep a separate destination disk for the installed appliance.
  3. Boot the guided console. If it must be started from the live root terminal, use soda-install disk. Follow the complete installation procedure.
  4. Review the displayed destination disk identity, network, hostname, root password and Project subnet. The explicit disk erase confirmation is destructive; verify that the intended disk is selected.
  5. After installation, remove the media, boot the installed disk and log in with the chosen root password. Keep internet access for matching release payloads and first-start dependencies.
  6. From the installed root terminal, run /usr/libexec/soda/soda-install configure and complete operator setup. Trust the appliance's public root certificate on the intended clients.

The first useful result is trusted private browser access, a successful Project Join and a working browser terminal. Test direct Project SSH separately if you need it; a displayed address does not prove a route. Host root administration remains separate from developer accounts inside Projects.

Prepare one repository for factory work

Choose a repository with a fast, meaningful check command and a maintainer who can review the result. Configure the native forge's required checks and review policy. A coding agent and a CI runner are different execution roles; follow the CI runner handbook for your check capacity.

Authorize repository automation, appliance resources and the appropriate provider sponsorship separately. Once configured, SodaOS automatically picks up authorized issues and runs the development loop through policy-governed merge. Give the first objective a small scope and explicit acceptance outcomes. Avoid beginning with a broad rewrite, production credentials or unlimited retry assumptions. Use the issue-to-PR exercise to inspect the whole loop and optionally test a human approval gate.

Observe and recover

Use Spaces and native Forgejo to inspect progress, candidate commits, reviews and check outcomes. Provider availability, unresolved requirements or exhausted limits can interrupt work. Resolve the actual cause rather than treating every interruption as a reason to restart the agent.

The private operator interface can inspect recorded runs:

soda-factory --socket /run/soda/operator/operator.sock status

Run it from the authorized operator environment described in the operator reference on GitHub. This status command does not enroll a repository or launch a task. A finished run and completed cleanup are separate observations.

Before expanding the factory

Verify a restore procedure, a provider interruption and a deliberate stop of one run. Record host usage during a representative build before increasing concurrency. Keep private ingress and console recovery available. The appliance is not automatically a highly available cluster; a host outage affects the Projects it runs.

If you need to retain an existing Linux host, evaluate the separate Docker path through Download. Its privileged runtime has host administrative authority. Continue with multiple Projects or private infrastructure.