# Operate an AI software factory on private infrastructure

Plan private access, provider data flows, credentials and recovery for a SodaOS factory on hardware or virtual machines your team controls.

Self-hosting places the factory's repositories, coordination services and development environments under your team's operation. It does not automatically make every AI operation local, every connection private or every workload safe. Define those boundaries before enrolling accounts or placing sensitive code in a Project.

## Private ingress

Install on a dedicated machine or compatible VM with console access. Keep browser, host administration, Git and Project services on their intended private network. Configure private connectivity before first setup rather than opening the unfinished installer to the public internet.

Trusted browser access requires both reachability and certificate trust. Direct Project SSH and application ports need their own client routes. A working browser session or enrolled host Tailnet does not prove direct reachability to every Project. The [Tailscale handbook](/docs/tailscale) explains the optional private connectivity path; LAN access remains a valid operating model.

## Understand outbound AI traffic

The factory uses configured coding-provider connections and TypeSafe/JEV for its respective execution and coordination decisions. Those services may receive source, task descriptions or other context relevant to their work. Hosting Git and Projects privately does not keep that provider-bound context on the appliance.

| Flow | What to decide |
| --- | --- |
| People to private forge and Spaces | Which clients and identities may reach the service, and how certificates are trusted |
| Agents to coding providers | Which repositories and data classes may be processed, under which account and provider terms |
| Coordination to TypeSafe/JEV | Which work and policy context is sent for judgments |
| Installation and updates | Which release hosts, registries and dependency endpoints are allowed |
| Projects to development services | Which internal networks, credentials and data sets the workload may access |

Review provider terms and organizational data requirements for the actual account configuration. This architecture is not a claim of air-gapped operation, local model inference, legal compliance or a specific data residency guarantee. See [company operation](/platform) for the broader responsibilities.

## Credentials and authority

Keep repository policy, appliance capacity and provider sponsorship separately authorized. The Identity Broker owns provider credential custody and execution-bound access; native Forgejo owns repository permissions. An agent-generated instruction, issue comment or model judgment must not create a new grant.

Use the least access needed for the selected workflow and plan withdrawal of sponsorship. A credential becoming unavailable is an intervention condition, not permission to use another person's account or silently change the billing path. The [credential reference on GitHub](https://github.com/LevitateOS/sodaos/blob/main/docs/reference/credentials.md) describes the account boundary.

## Containers, hosts and trust

Projects are persistent containers sharing the host kernel. Human and factory accounts are distinct, but the project environment contains shared tools and services. SodaOS targets a trusted team on an operator-managed appliance, not a public service executing hostile code for unrelated tenants.

The Docker deployment is especially important to distinguish: its privileged runtime and host networking grant host administrative authority. Use a dedicated Linux host and the documented retained volumes. It does not offer a hardware sandbox or the CoreOS appliance's SELinux dashboard confinement. Review [Docker requirements](/docs/docker) and the [trust model on GitHub](https://github.com/LevitateOS/sodaos/blob/main/docs/architecture/trust.md).

## A practical acceptance exercise

Before onboarding a team, verify private browser access from an intended client and refusal from an unintended network. Check a Project terminal and direct SSH separately. Document the outbound services your selected installation and AI workflow use. Test revoking a user's project access and withdrawing a provider grant in a disposable workflow.

Create and restore a backup of representative forge, platform and Project data. Keep console recovery outside the factory's own account dependencies. Record what passed and what could not be verified; do not infer isolation or recovery success from a configuration file alone.

Use [dedicated-server setup](/use-cases/dedicated-server) for installation and [review and approval](/use-cases/review-and-approval) for a small workflow. If your requirements demand different tenancy, provider or network boundaries, compare [a custom agent platform](/compare/custom-agent-platform).