Sovereignty
Loha exists because the Thai market needed a CI/CD platform that doesn't ship source code, secrets, or build artifacts to a foreign cloud. This page explains what "sovereign" means concretely: not as a marketing term, but as a set of enforceable boundaries.
The problem
Most CI/CD products are SaaS in a foreign cloud. Using them means:
- Source code leaves Thailand.
- Build environment variables (including secrets) are stored in a foreign jurisdiction.
- Build artifacts and container images live in foreign registries.
- Personal data flowing through CI (test fixtures, log content) leaves Thailand.
Under PDPA and emerging public-sector procurement rules, that's a problem. Foreign data localization is a hard limit for many Thai government, finance, and healthcare buyers.
What Loha guarantees
Loha is built so that every component runs in a Thai datacenter, controlled by a Thai operator, with no path for data to leave the country during normal operation. Specifically:
| Layer | What stays in Thailand |
|---|---|
| Source code | Cloned into ephemeral, in-cluster workspace storage. Never copied off-cluster. |
| Secrets | Encrypted at rest with AES-256-GCM. Stored in Thailand. Decrypted only inside the build pod that needs them. |
| Build environment | Every build pod runs on Thai datacenter compute. |
| Container images | Pushed to the container registry you configure: choose an in-country registry to keep them in Thailand. |
| Build logs and artifacts | Stored in Thailand. Retention is governed by your plan. |
| Audit logs | Stored in-country, retained indefinitely under current policy. |
| Webhook ingress | Terminates at the in-country dashboard, not a third-party proxy. |
What's not yet guaranteed (honest)
- Egress-blocking by default. Build pods can technically reach the public internet today if a step explicitly does so (e.g., to fetch a dependency from npm). This is a deliberate trade-off (most pipelines need package downloads), but it means runtime egress is not yet blocked by default. Per-workspace egress allowlists are on the v1.1.0 roadmap.
- Region-pin runtime proofs (cryptographic evidence that a given build executed on a specific cluster) are also v1.1.0 work.
- Customer-managed secret backends (bring-your-own secret store) are v1.1.0. Today the secret store is operated by Loha.
If any of these are mandatory for your use case, the roadmap tells you when to expect them.
How customers verify sovereignty
- Audit log is exportable from the dashboard: every privileged action, every secret access.
- Image registry transparency: you can inspect every layer of every image stored in your workspace.
- Open architecture: every component in the data path is open-source. There is no Loha-proprietary opaque service handling your code, secrets, or images.
- Site visits: enterprise customers can request a tour of the Thai datacenter where their workspace runs.
Related reading
- Multi-tenancy: how one workspace is kept separate from another
- Secrets management: how secrets are encrypted, scoped, and injected