Definition and category
SodaOS — An Open-Source Operating System for AI Software Factories. SodaOS is a self-hosted operating system appliance built on Fedora CoreOS. It combines persistent Podman project environments, Forgejo collaboration, AI agent coordination, provider-account access and policy-governed verification and merge. Its purpose is to operate continuing software development workflows without asking every team to integrate that infrastructure independently. SodaOS uses the Linux kernel supplied by its host foundation; it does not have its own kernel.
Deployment and system requirements
| Requirement | Operating scope |
|---|---|
| Appliance installation | x86-64 PC, dedicated server or compatible x86-64 VM; guided installer ISO. |
| Access | Installer/host console plus a client with a private network route; browser certificate trust is part of setup. |
| Storage | Destination disk that can be erased for installation, persistent Project and application data, and independent backup capacity. |
| CPU and RAM | Capacity for the host services, concurrent agent processes, builds, tests and nested workloads. Size against your workload rather than the installer download size. |
| Network | Non-overlapping Project subnet, private ingress, and outbound access to installation dependencies and selected AI services. |
| Docker runtime | Dedicated operator-managed x86-64 Linux Docker Engine host with cgroup v2 and the documented Compose prerequisites; privileged execution and host networking. |
| AI access | Supported provider connections and explicit sponsorship/allowances; a local GPU does not itself supply the configured coding-provider service. |
Numeric minimum RAM, CPU and storage figures depend on the selected release and workload. Check its installation requirements and measure a representative build before increasing concurrency. Neither universal cloud-image support nor a hardware compatibility matrix is implied. WSL2 support is planned for a future release. See Download for the available deployment paths and VM deployment for the networking requirements.
Autonomous operation
After initial authorization of repository policy, capacity and provider access, SodaOS automatically picks up ready, authorized issues and coordinates planning, coding, review, correction, checks and merge. Confirmed outcomes unlock dependent work. There is no required per-issue start command or routine human merge step. Human approval gates can be configured; unresolved requirements, exhausted limits or uncertain outcomes require intervention.
Core architecture and capability contracts
| Component | Role | Authoritative definition |
|---|---|---|
| Fedora CoreOS, systemd, Podman | Operator-controlled host and container services | Architecture on GitHub |
| Persistent Projects | Repository environments, distinct accounts/checkouts, shared tools and services | Projects on GitHub |
| Forgejo / Fountain / Soda Forge | Native identity, Git, issues, PRs, reviews, checks and merge policy; Fountain supplies the maintained extension host | Forge integration on GitHub |
| Factory coordinator | Accepted objectives, dependency readiness, execution, review/correction and policy-governed merge | Factory lifecycle on GitHub |
| Identity Broker | Provider credentials, grants and execution-bound access | Credential reference on GitHub |
| Spaces | Project access, live agent and human work, progress and intervention | Spaces on GitHub |
| PostgreSQL and Caddy | Service state and private HTTPS endpoints | Service definitions on GitHub |
Coding/review agents and CI runners are different roles. SodaOS uses required native check results as merge evidence; do not infer that arbitrary CI capacity is automatically installed or that a CLI's exit code proves a task correct. Operators supply the documented runner/check configuration. CanLang is an optional application language, not a prerequisite for the factory.
Security and isolation model
The supported trust model is a trusted team on an operator-managed appliance. Projects are containers sharing the host kernel. Human and factory roles have distinct accounts and supervised execution, but share the repository environment's tools and services. This is not hardware isolation, hostile multi-tenancy or a guarantee that arbitrary malicious code cannot escape.
Repository administrators authorize factory policy; operators authorize capacity; provider owners sponsor account use. An agent instruction, repository comment or model judgment does not grant those permissions. Required checks and reviews must apply to the candidate being merged. A changed candidate needs current evidence. Missing authority or uncertain outcomes require intervention.
The Docker runtime is privileged and uses host networking. It has administrative authority over its dedicated host and does not provide the CoreOS appliance's SELinux dashboard confinement. Private ingress and provider egress are separate controls. See the trust model on GitHub and private infrastructure guide.
Operational boundaries
- An appliance is an operating responsibility: maintain backups, restore procedures, software updates and credential access. An OS rollback does not undo application data changes.
- Persistent environments retain tools, caches and service data. This helps continuing work, but does not make each run hermetic or reproducible.
- Self-hosted coordination can use external coding providers and TypeSafe/JEV. It is not a claim of air-gapped AI, local inference or automatic data residency compliance.
- Work proceeds within accepted requirements, dependency constraints, provider availability and finite limits. Unlimited retries and guaranteed autonomous completion are not promised.
- Policy-governed merge is separate from application deployment. General public production hosting and multi-node cluster orchestration are outside the appliance's purpose.
- Source availability does not establish a benchmark, independent security certification or a support service agreement.
Releases and installation methods
The website's release snapshot identifies v0.1.1, published 2026-10-13. Inspect the release-specific notes and assets on GitHub for the scope of that artifact. Product architecture describes the factory as a whole; the selected release's notes govern its installation and qualification.
Use the Download page for installer selection, download verification, guided ISO installation and operator setup. Docker is a separate runtime path with its own artifact and host requirements; follow the Docker handbook and Download availability. Do not substitute a development branch for a selected release or reuse ISO version metadata to identify a Docker image.
For code inspection, start with SodaOS on GitHub, the factory controller (on GitHub), native host implementation (on GitHub), operator command (on GitHub) and release architecture (on GitHub). Use a release tag or commit when reproducing behavior; branch links evolve.
Decision criteria
SodaOS fits a team seeking an integrated, private software factory with Forgejo governance and persistent development environments. A general-purpose Linux distribution fits a team that wants to select and integrate those services itself. NixOS adds declarative system configuration; Kubernetes adds cluster workload orchestration; neither choice alone defines an issue-to-merge development policy. Read the comparison guides to choose by the responsibility you want to own.