SodaOS — An Open-Source Operating System for AI Software Factories

SodaOS is an open-source operating system appliance for autonomous AI software development. Built on Fedora CoreOS, it integrates the environment in which coding agents work with the repositories, credentials, checks and decisions that govern their work. A team can operate a self-hosted software factory without assembling each of those systems separately.

The normal development loop is fully autonomous under standing authorization: SodaOS picks up ready issues, plans and codes, reviews and corrects candidates, runs through required checks, merges, and continues with dependent work. People set goals, access, budgets and policy. They do not need to start every issue or merge every pull request.

What is an AI software factory operating system?

An AI software factory turns accepted objectives into maintained software through a repeatable development process: choose ready work, prepare an environment, run a coding agent, publish a candidate, review and correct it, check it, and merge under repository policy. People set the objectives and boundaries and resolve decisions that need their judgment.

An operating system for that factory combines the Linux host with the development infrastructure and workflow coordination. This is a description of the product category, not a separate kernel technology or an industry certification. Installing an agent CLI on Linux supplies an execution environment; operating a factory also requires persistent state, accountable access, dependency handling, verification and recovery.

What SodaOS provides

The architecture contract on GitHub defines these responsibilities. The technical reference collects deployment requirements, boundaries and source locations.

Architecture and trust boundaries

People: objectives, repository policy, capacity and account grants
   |
   v
Private browser / SSH access
   |
   +-- Soda Forge (Forgejo): issues, Git, PRs, reviews, CI state
   +-- Spaces: visibility and human intervention
   |
Factory coordinator -- Identity Broker -- authorized AI provider
   |
   +-- Podman Project A: human + coding + review accounts
   |      separate checkouts; shared tools and project services
   +-- Podman Project B: its own repository environment
   |
Fedora CoreOS / Linux kernel -- operator-controlled machine

Projects share the host kernel. Separate accounts and supervised processes bound access and lifecycle; they are not hardware-isolated virtual machines or a guarantee of safe execution for hostile tenants. The operator and installed platform components remain trusted. Repository text and agent output do not grant platform authority.

Self-hosting controls where the factory and its data live. Coding providers and TypeSafe/JEV can receive task context for their respective work; self-hosting does not imply offline AI or that no data leaves the network. Read the private infrastructure guide before selecting an access or data policy.

How agents are coordinated and supervised

A repository administrator enables the workflow and selects its standing policy. The operator authorizes capacity; provider-account owners authorize the connections and allowances. SodaOS automatically picks up new authorized issues and reconsiders changed or unblocked work. Work generated from an accepted product direction carries that direction's bounded authority. Unresolved dependencies or material questions keep work blocked; exhausted resources make it wait or request intervention.

Coding agents work inside persistent Projects. SodaOS ties a candidate to its issue, attempt and exact commit. A separate agent session reviews the change, corrections receive current verification, and configured CI checks and repository protections govern automatic merge. Human approval gates are optional policy choices; human intervention resolves exceptions such as a material unanswered question. Integration is separate from deploying an application.

The factory product contract on GitHub explains the complete loop. Follow the review and approval walkthrough for a small issue-to-PR exercise.

Why use SodaOS instead of a general-purpose Linux distribution?

NixOS, Ubuntu Server and Debian can all host coding agents. The choice is who supplies and maintains the factory above the host. SodaOS integrates repository environments, coordination, provider access and review into one appliance. A general-purpose distribution gives you more freedom to assemble a different stack and makes you responsible for its integration.

Fedora CoreOS is SodaOS's underlying host, so the choice there is a base container OS versus the integrated factory built on it. Talos Linux and Kubernetes solve cluster infrastructure problems; they can support a custom factory, but cluster scheduling alone does not decide whether an issue is ready or a pull request should merge. See the comparison and decision guides.

Install and operate the factory

1. Choose an x86-64 PC, dedicated server or compatible virtual machine with console access, an erasable destination disk and private client connectivity. Size CPU, RAM and storage for your builds, concurrent agents and retained data.
2. Select the installer through Download and verify its release artifacts. Keep internet access available for release payloads and first-start dependencies.
3. Boot the ISO and use its guided console. Review the exact disk, hostname, network and Project subnet before confirming the disk erase. Follow installation on premises.
4. Complete operator setup, trust the appliance certificate on intended clients, and verify sign-in, Project access and a real terminal.
5. Prepare a repository, its required CI checks, provider sponsorship and execution limits. Start with one bounded objective and inspect its PR and checks before expanding automation.
6. Maintain backups, access policies, provider connections and updates. Keep a recovery path independent of the factory itself.

Docker offers a distinct deployment of the factory runtime on an operator-maintained Linux host; its privileged runtime has host administrative authority. Use the deployment choices and release-specific instructions on Download, rather than treating a generic Docker container as a sandbox.

When to choose SodaOS

Choose SodaOS when a trusted team wants a dedicated, self-hosted environment for continuing AI development; values integrated Forgejo workflows and persistent Projects; and can appoint an operator for credentials, network access, backups and policy. It is particularly relevant when the problem is coordinating several development workflows, not simply starting one agent.

Choose a general-purpose distribution when you want one CLI, need a substantially different forge or provider architecture, or prefer full control over each service. Choose a Kubernetes-based platform when multi-node scheduling and an existing cluster operating model are central requirements. Choose an appropriate VM or other isolation design when executing hostile code for unrelated tenants. SodaOS does not claim automatic high availability, universal hardware support, deterministic AI output or guaranteed correctness.

CanLang and custom enterprise software

CanLang is an independent language for business applications: records, permissions, workflows and interfaces. SodaOS coordinates development; CanLang supplies application constructs. Teams can use them together to build and maintain software around their own operations, or use other languages in SodaOS Projects. CanLang is optional, and example business applications are illustrations of what teams can build.

Continue with the technical reference, practical use cases, product handbook or SodaOS source on GitHub.