A software factory is an ongoing development process, not just a machine with an agent installed. These guides connect installation and access to the work a team wants to supervise. Each identifies the operator's responsibilities, a useful verification step and the boundary of the result.
SodaOS runs that process autonomously under the initial goals, grants and standing policy: it picks up ready issues, codes, reviews, corrects, checks, merges and continues. Optional human approval gates and exception handling let a team choose where human judgment is required.
Choose your task
| Task | Guide | Useful outcome |
|---|---|---|
| Give coding agents a dedicated machine | Dedicated-server factory | Installed appliance, trusted private access and a bounded first repository |
| Build a self-hosted factory | Dedicated-server factory plus review workflow | A path from operating the host to evaluating a reviewed change |
| Run several development projects | Multiple Projects | Separate repository environments with explicit capacity and access |
| Supervise generated pull requests | Review and approval | Candidate-specific checks, review, correction and confirmed integration |
| Require human approval before merge | Review and approval | An enforced policy decision rather than a prompt asking the agent to wait |
| Keep the factory on private infrastructure | Private infrastructure | A deliberate ingress, provider-egress and recovery design |
Begin with one bounded workflow
Select one repository whose maintainer can define a small, testable outcome. Establish required checks before granting unattended work. Record who owns repository policy, appliance capacity and provider access; one person can hold several roles, but the authorities remain separate.
Try the change as a user after the reviewed PR is merged. A green build and a completed merge establish different facts from an accepted business workflow. If the change needs deployment, make that a separate authorized operation and verify the running application.
Operate beyond the first result
Keep project data and service backups, test restoration, monitor storage and provider limits, and assign an operator who can investigate interruptions. Retained environments help subsequent work but also retain caches, tools and data that need maintenance. Expanding to more projects should follow observed capacity and successful intervention procedures.
These are procedures and worked examples, not recorded customer deployments or benchmark results. The technical reference describes the architecture and operating scope. If you are still choosing infrastructure, start with the factory OS overview and comparisons.