Build a custom platform when your required workflow or execution boundary is materially different from SodaOS's trusted-team, persistent-Project, Forgejo-based model. Choose SodaOS when that model fits and you want to operate the factory rather than maintain the integration between its parts.
What you are actually assembling
A coding CLI is one component. A continuing factory also needs to know what is authorized, when work is ready, which environment and account to use, and what constitutes a verified result. A small script may be entirely sufficient for one developer; a shared unattended workflow has more states and authorities to account for.
| Responsibility | Questions for a custom design | SodaOS's integrated model |
|---|---|---|
| Selecting work | Who accepts the objective? What invalidates it? | Accepted native requirements and current repository authority |
| Dependencies | How does a prerequisite block and later unblock work? | Readiness assessment and reconsideration after relevant outcomes |
| Environments | What persists, and what belongs to one execution? | Persistent Projects with separate accounts, checkouts and supervised runs |
| Credentials | Who sponsors access, with which limits and revocation behavior? | Identity Broker and separately authorized provider grants |
| Review | Who reviews which exact candidate, and what happens after corrections? | Separate review sessions and current candidate evidence |
| Integration | How are CI, protections and merge authority enforced together? | Required checks and native Forgejo policy-governed merge |
| Recovery | How are unknown external outcomes reconciled without repeating effects? | Recorded work and intervention when safe continuation is uncertain |
These are design responsibilities, not a claim that every custom platform needs a large new framework. Existing mature tools can provide many of them. Evaluate their seams: one service's successful job should not silently become another service's authorization to merge.
Extensibility versus integration
A custom platform lets you choose another forge, ephemeral environments, VM isolation, a different provider model or a multi-cluster topology. That flexibility is valuable when it addresses a real requirement. It also makes your team responsible for upgrades and failures across those boundaries.
SodaOS makes opinionated choices so its components share an operating model. Developers retain ordinary Git, SSH, tools and languages inside Projects, and CanLang remains optional. Replacing the native collaboration authority or execution topology is a larger change than configuring a project; do not assume every existing workflow is a drop-in fit.
Security and ongoing cost
Compare the trust model, not just the container runtime. SodaOS trusts the operator and team; Projects share the kernel. A custom design can use a different boundary, but the guarantee comes from its implementation and configuration. Privileged containers, shared credentials or broad forge tokens can undermine an otherwise careful design.
Budget for operator time, compute, storage, backups, coding-provider access, coordination services and maintenance. SodaOS does not eliminate those costs, and this guide makes no measured savings claim. A team with a working platform may reasonably prefer incremental improvements to replacing it.
A decision worksheet
Write down the non-negotiable requirements: forge, tenancy, data egress, host/cluster model, provider access, required review and recovery objectives. Mark which the proposed system supplies, which your team must configure and which require custom code. Then run one issue through a PR, a correction, approval and merge, followed by an interruption drill.
Choose the smallest architecture that covers those requirements and that your team can maintain. Use the SodaOS technical reference, private infrastructure guide and factory lifecycle contract on GitHub as the SodaOS side of that assessment.