Bring the Soda OS software factory to your infrastructure, or use CanLang on your own computer to build business apps.
Illustration · the host stays operator-managed.
Run the complete software factory, Projects and nested containers on a dedicated Linux host. You maintain Linux; the privileged runtime has administrative authority over that host.
x86-64 Linux · Docker Engine
Docker support in preparation
Explore Docker deploymentIllustration · install Soda OS and its factory.
Install Soda OS and its factory with the same released x86-64 ISO on compatible hardware or a VM. Complete installation, then establish verified private browser access.
x86-64 · USB or virtual machine
Available · v0.1.1
Choose ISO installationComplete task starter
# Track the team's work.
app Tasks
Given
export Todo { title:text trim, done:bool=false }
policy Todo read=members
When
crud Todo by=members fields=title,done
Then
page / title="Tasks"
form Todo.create fields=title,done display=inline
input title
checkbox done
list Todo
text row.title,row.done
edit fields=title,done
delete
Illustrative task app · sample records.
Build business apps with your editor and AI, independently of Soda OS. Install the language, then run the small task app on your own computer.
macOS Apple Silicon · Linux x64 (glibc 2.39+)
Available · v0.1.1
Install CanLangThe installer selects your platform and includes the runtime.
Then build your first appInstall CanLang
curl -fsSL https://sodaos.dev/CanLang/install.sh | bashv0.1.1 release on GitHub · No separate Rust, Node, Bun or npm setup. Browser tooling is optional.
Run the complete Soda application runtime, including Projects and nested containers managed by Podman. You maintain the underlying Linux host operating system.
Illustration · the host stays operator-managed.
A public Docker installation is not available yet. The install command will appear here once the container image and setup files have been published and verified together.
See how the factory runs on an existing host, what it needs and how to retain your team’s work.
Read the Docker operator guideUse x86-64 Linux with cgroup v2, rootful Docker Engine and Docker Compose 2.17 or newer. Have curl, jq, coreutils and OpenSSL available for setup.
Systemd and nested Project containers managed by Podman require privileged execution. The runtime has administrative authority over the host; it is for a trusted team on dedicated infrastructure.
Use host networking with IPv4 forwarding, a private address your team can reach and a Project subnet that does not overlap your existing networks. Keep the required HTTPS, Git and Cockpit ports available; the guide lists the exact bindings.
Allow several gigabytes for the runtime, plus capacity for your Projects and backups. Plan persistent storage before starting the service.
/etc/var/homeKeep the same Compose project: sodaosRetain the named volumes for /etc, /var and /home, and keep the same Compose project name, sodaos. Recreating the container with the same image then preserves configuration, credentials, repositories and Project data. Version changes need a separately verified upgrade path. Follow the guide for setup, backups and recovery.
Rootless Docker and Docker Desktop are outside this Linux deployment contract. macOS/Apple Silicon Docker Desktop and the ARM64 UTM ISO remain backlog work. Follow compatibility work on GitHub. There are no downloads for these paths here.
Release availability checked 2026-10-16.
Choose your boot method, then follow the guided disk installation. Keep internet access to GitHub available through first startup, when Soda downloads its required components.
Installation needs internet access to GitHub. It erases the selected disk only after you confirm. Back up anything you need to keep before installing. Read the ISO installation guide.
sodaos-x86_64.iso. Required components download at first startup, after disk installation.Illustration · install Soda OS and its factory.
Write the ISO to a USB drive with a disk-image writer, then boot your compatible x86-64 PC from it. Writing replaces the USB drive’s contents; installation separately asks you to confirm the destination disk.
USB installation instructionsCreate a compatible x86-64 VM with a separate destination disk and attach the ISO as its optical disk. Keep console access and a private network route from your browser to the installed appliance.
Virtual-machine installation instructionsWSL2 support for x86-64 Windows gaming PCs is planned for a future release. No WSL2 download is available.
You can use compatible x86-64 hardware you already own: a workstation, dedicated mini PC, gaming PC or server. Check the selected release’s hardware guidance before installing.
After disk installation and reboot, keep internet access available while first startup downloads the matching required components. Use your installation password at the local console or over verified SSH and run soda-install configure. Follow guided Forgejo setup, verify and trust the displayed local CA certificate, then open the private HTTPS address. SSH keys are optional.
First startup, operator configuration and verified private browser access are separate setup outcomes.
After the chosen route’s setup, the department and operator work toward the same result: a running workflow your department has tried and accepted.
Private address reached + people signed in
Operator and participating users
Reach the verified private browser address from the intended client. People can sign in with appropriate native accounts; a displayed URL or active service alone is not the check.
Set up private accessRepository + persistent Project prepared
Operator, maintainer and department owner
Prepare the repository and persistent Project. Agree supported AI access, execution authority, capacity and review policy, then accept the business outcome together.
Prepare the ProjectReviewed changes + traceable evidence
Soda, with people resolving questions
Accepted direction becomes native work and reviewed changes. People clarify requirements or intervene; integration follows repository policy and evidence tied to the exact candidate.
Follow the factory walkthroughRunning workflow + business acceptance
Department owner and relevant users
Start and reach the application, then check its agreed behavior with permitted test data. Accept the business result and make an explicit application deployment decision.
Try the equipment workflowAccess lets people reach the factory. Authorisation controls AI work. Review and merge follow repository policy. Deployment is a separate decision.
Browser sign-in, repository permission, human Project membership and factory authority are separate. Join project provides a person’s development access; it is not agent admission or a requirement for every department participant.
Developers can keep their editor, terminal and optional SSH access.Use an illustrative starting brief, adapt it to your company and agree it before development. This is an application the factory helps your company create.
The starting briefWe need employees to request equipment from our catalogue. A reviewer must approve someone else’s request before Operations records delivery. Employees should see their own requests, and approved details should stay protected.
Approval and recorded delivery
When
crud Equipment by=coordinator fields=name,category,active delete=none
crud Request by=members fields=equipment,reason when=row.requested_by==actor and row.status==requested delete=none
# Review another teammate's request against the equipment catalogue.
scenario approve(request:Request) by=reviewer
require request.status==requested and request.requested_by!=actor
require request.equipment.active
do set request {status=approved,approved_by=actor,approved_at=now}
# Record the physical asset when approved equipment reaches the requester.
scenario deliver(request:Request,asset_tag:text) by=coordinator
require request.status==approved and trim(asset_tag)!=""
do set request {status=delivered,asset_tag=trim(asset_tag),delivered_at=now}
Illustrative application interface · sample records.
Avery requests an active catalogue item and follows Requested → Approved → Delivered.
The requester cannot approve their own request. An authorised reviewer approves another person’s eligible request; repeated approval is refused.
An unrelated ordinary employee cannot read Avery’s request. Authorised reviewer and coordinator queues remain available.
Operations records delivery only after approval, with a nonempty asset tag.
Approved request details and completed delivery details remain protected. Reopen the application to see the saved result.
Business approval in this application and code review in the factory are distinct. The complete story links its canonical larger source; the compact CanLang browser demo illustrates fewer rules.
Install → save the task source → check and start → open the returned preview → add, edit, archive and reload a task. Continue with the language handbook and application deployment guide.
For a PC or virtual-machine installation, the ISO is the only download you need. These materials describe the ISO release and provide independent verification and source inspection.
# SodaOS v0.1.1
Download `sodaos-x86_64.iso` and boot it to install SodaOS on an x86-64 PC or VM. The installer automatically downloads the matching root filesystem from this GitHub release; no component assembly or custom download server is required. Installation needs internet access to GitHub.
This release updates Fountain to Forgejo 15.0.10 LTS, including security fixes for fork pull-request review/comment secrets and attachment/label metadata access. It preserves organization-label removal by ID and fixes runner-log retries and finalization. Fountain is built with Go 1.26.9 and updated dependencies.
Release publication now requires successful hosted CI for the exact Soda source commit and its pinned Fountain source. Fountain's corresponding source archive comes from its own repository and is included here beside the OS binaries.
Soda source: `68d824014566966c432258d6f87d27f0c675ae51`.
Fountain source: `fd7890e0ae88a3d65fdafd713dd70f5a489a1336`.
Source CI and focused security/regression checks passed. The broader Actions synchronization test limitation remains documented in [Fountain PR #1](https://github.com/veighnsche/forgejo-ext/pull/1). Native installation qualification is recorded below when promotion completes.
Source CI: https://github.com/LevitateOS/sodaos/actions/runs/38470093763
Native install and first-boot smoke checks passed for the unchanged release bytes.
```json
{
"format": 1,
"soda_revision": "68d824014566966c432258d6f87d27f0c675ae51",
"forgejo_revision": "fd7890e0ae88a3d65fdafd713dd70f5a489a1336",
"iso_sha256": "d65476940bb77c08b998c48327ad96bacc2c7cdbf44173605040013ec5ec9148",
"rootfs_sha256": "71f9af21ed733047147cb1f48e0d446c2c19df50a68a766ee3358e4c253c0114",
"downloaded_iso_sha256": "d65476940bb77c08b998c48327ad96bacc2c7cdbf44173605040013ec5ec9148",
"observed_soda_revision": "68d824014566966c432258d6f87d27f0c675ae51",
"install": "passed",
"boot": "passed",
"applications": "passed"
}
```