Your cloud. Your network. Your data stays where you put it.
AnantState is installed in infrastructure you control: your cloud account or your network. There is no shared service run by us that your data passes through. It runs behind your security controls, beside your systems, and changes things only through recorded actions.
In plain termsYou install it, you run it, and your data stays on your side.
At a glance
Three supported topologies
Single-host containers, Kubernetes, or your cloud account with a managed database.
Isolation in the database
Tenant separation is enforced below the application.
Read-mostly by default
No write access to production systems is needed to be useful.
Upgrades without a data migration first
The platform upgrades independently of your data.
Three supported topologies
The same services in each. What changes is how they are hosted.
| Topology | Shape | Typical use |
|---|---|---|
| Single-host containers | The whole stack in one container composition: database, API service, web application and an optional identity provider for testing | Evaluation, a first domain, a restricted environment with one machine |
| Kubernetes | The same services deployed to an environment that already runs a cluster | Production in an estate that already standardizes on a cluster |
| Your cloud account with a managed database | The application services beside a managed database instance, with provisioning and retention scripts | Production where the database is a service your team already operates |
In every topology the store is a standard relational database, and a vanilla install is a supported target, not a degraded one. Migrations run at boot, and the serving role has isolation enforced on it rather than superuser rights. Provisioning a database and serving traffic from it are separate privileges, which is the property a security reviewer looks for first.
What stays under your control
Because it runs in your environment, the controls are yours.
The platform is observable as a first-class property. Health, throughput and latency are exposed as metrics, so your operations team can run it with the tools it already uses.
Isolation that survives a bug
Whether you run one tenant or many (business units, subsidiaries, environments), isolation is enforced by the database itself. An application defect cannot widen visibility, because the application’s failure mode is closed rather than open. There is no shared queue or shared execution context between tenants, so one tenant’s heavy reasoning cannot occupy the capacity another’s live operation depends on.
Read the full set of layers on cloud native and multi-tenant and the controls on governance.
Fitting it into your estate
Choose the topology
Match it to how your team already runs software. A first domain often starts on a single host and moves to a cluster or a managed database without changing the design.
Connect identity
Single sign-on over OIDC, directory provisioning over SCIM, and multi-factor authentication at login.
Connect events
Streams, REST sources, scheduled pulls or bulk import, all landing as events. See event-driven.
Set limits and authority
Budgets, limits and the action framework are declared before anything is allowed to act.
What we do not claim
Walk your platform team through it
Bring your cloud environment, your network constraints and your identity setup. We will say what fits, what needs a conversation, and what we would test first.