The Soda OS platform
Build and keep improving internal tools on infrastructure your company operates. Departments define what the software must do. Soda OS coordinates AI development and review; IT manages access, capacity and operation.
Company-operated infrastructure, supported AI connections and a named technical operator.
Persistent Projects — a lasting workplace
Choose a dedicated Linux host or install Soda OS itself. Compatible x86-64 gaming PCs, workstations, mini PCs, servers and virtual machines let you use infrastructure you already own.
Illustrative hosting layers
Run the complete Soda application runtime, including Projects and nested containers. Your operator maintains Linux; the privileged runtime has administrative authority over its host.
Illustrative hosting layers
Install the operating system and factory on compatible x86-64 hardware or a compatible x86-64 virtual machine.
WSL2 support for x86-64 Windows gaming PCs is planned for a future release.
Managed Soda servers are planned after launch. At launch, your team deploys and operates its own Soda server.
The independently usable language has its own path: explore CanLang.
Keep business direction, repository collaboration and development connected.
Peopledefine outcomes and accept the result
Responsibilities, not execution order.
CanLang is an optional language for application source.
Company operators provide infrastructure, access and capacity.
Soda turns accepted direction into ready work, then coordinates investigation, implementation, independent review and correction.
From direction to delivery
People define outcomes and resolve questions.
Check prerequisites, access and the Project.
Inspect the repository and plan implementation.
Agents implement and report a candidate with evidence. Soda publishes the pull request.
Another agent session reports findings.
The coding role fixes findings; checks run again.
Required evidence and repository rules govern merge.
Continue ready work or revise the plan.
Direction, execution, independent review and policy-governed integration.
Questions or limits can pause progress. Merging code and deploying an app are separate actions.
Read the factory walkthroughIssues, code, pull requests, discussions, reviews and checks share a repository home.
Accepted direction, a candidate and its evidence stay connected to the result.
Capture outcomes and prerequisites in native issues.
Connect proposed changes, findings and checks.
Link accepted direction, Soda’s execution records and integration.
Source, commits and collaboration in Soda Forge. This capture shows a newly initialized repository with its first README commit.View full size
Built on Fountain, the maintained Forgejo fork.
Explore repository collaborationA Project retains tools, files, accounts and services between requests. People, coding agents and reviewers use separate accounts and checkouts.
Separate runs share a lasting development home.
Tools and service data remain when a run ends.
See activity with its issue, candidate, findings and checks.
Clarify, pause or cancel. Take over in your own account after factory execution stops.
Projects, saved plans and progress in the Work view. This interface capture uses sample projects and plan content.View full size
Closing a view does not cancel work. Stopping the Project stops sessions and services, while durable files remain.
Explore Projects and accessCreate a Soda Forge repository or import existing Git code. Keep hands-on development in your preferred editor and terminal.
Choose a starting point
Persistent Project
Create or import a repository, then keep separate checkouts in its associated Project.
Verify the import and configure access and policy. Import is not automatic synchronization.
Join project grants a personal account. Prepare your checkout, then use the browser terminal, SSH or your editor.
You can also clone from another Git host into your own checkout.
Factory work also requires accepted direction, a prepared Project and explicit authorizations.
Define the records, access and rules that fit your company. CanLang connects them to standard operations and interfaces.
One application source
One application source connects records, access, rules and interfaces.
Typed records, relationships, validation and storage.
Authentication, team context and explicit permissions.
Standard record operations, business rules and guarded actions.
Forms, tables, filters and actions using the same records.
Interface excerpt
Then
page / title="Equipment requests"
form Request.create
list Request
text row.item
badge row.status
action approveFor the remaining gaps, extend with $.
Generate saved, editable implementation during development.
CanLang works independently. Using it in Soda OS is optional.
Keep repositories and development environments on infrastructure your team operates. Select supported AI connections and set the rules for authorized work.
Repository access, Project access and factory authorization.
Supported accounts, agent profiles and execution allowances.
Required checks, approvals and branch protections.
Updates, backups, private access and recovery.
Company-operated infrastructure
Requests and supplied context leave the company boundary; responses return.
Private applications, when the chosen deployment provides private access. A running development service or merged change does not establish production deployment.
Company responsibilities, external AI connections and application operation retain distinct boundaries.
What reaches external services? Requests and the context supplied to the selected service. Depending on the action and configuration, that can include repository content, task details and execution output. Review supported connection guidance before choosing accounts and permitted context.
Who authorises it? Your operator selects supported accounts and providers, permitted users, spending allowances and repository policy. Expired authentication or exhausted allowance interrupts work; Soda does not silently switch account, provider or billing method.
Self-hosting does not make every AI call local. The appliance serves a trusted team through private-network access. Shared-kernel containers do not establish hostile-tenant isolation; self-hosting alone establishes neither offline operation nor exclusive data residency.
Departments own requirements and acceptance. IT operates the shared foundation.
A department owner and technical operator can use this brief to agree a useful first result together.
Users, rules, exceptions and a result to accept.
Host, accounts, authority, capacity and continuity.
One agreed first result
Department and operator agree one useful first result together.
Start with equipment requests, onboarding, expenses, maintenance or a comparable process. Name its business owner, users, rules, exceptions and one result they can accept.
Choose a host route, supported AI connection, permitted test data, access and an initial resource allowance. Name who prepares the repository and Project, and who owns operation and recovery.
Follow the reviewed changes into a running trial. Agree which permitted and refused actions the department will check, and retain the evidence.
The department accepts the business result. Decide application hosting, access and maintenance separately, then return to the same Project for the next change.
Business acceptance and the application deployment decision are separate milestones.
After equipment requests work for your team, add Finance approval above €1,000 while preserving earlier requests. The source, history and persistent Project give the next change a lasting home.
Use compatible x86-64 gaming PCs, workstations, mini PCs, servers or virtual machines. Your team operates the factory.