Deployment Options
Two Ways to Run Infragnite
Section titled “Two Ways to Run Infragnite”| Cloud SaaS | Self-Hosted | |
|---|---|---|
| Hosted by | Infragnite | You |
| Setup | Sign up and connect providers | Deploy via Docker Compose or Kubernetes |
| Updates | Automatic | You control the upgrade schedule |
| Data isolation | Database-per-tenant | Single-tenant, your database |
| Best for | Teams that want zero ops overhead | Organizations with data residency or compliance requirements |
Both options use the same codebase and the same API. There are no feature differences between them.
Cloud SaaS
Section titled “Cloud SaaS”The managed option. Sign up, connect your providers, and start managing infrastructure immediately.
- Multi-tenant architecture — each organization gets its own isolated database. No data is shared between organizations.
- Automatic updates — new providers, features, and security patches are deployed without any action from you.
- Managed availability — we handle uptime, backups, and scaling.
Your provider credentials are stored encrypted and used only to communicate with your providers’ APIs.
Self-Hosted
Section titled “Self-Hosted”Deploy Infragnite on your own infrastructure for full control over data and access.
Requirements:
- Docker Compose or Kubernetes
- PostgreSQL-compatible database (MongoDB)
- OIDC-compatible identity provider (Auth0, Keycloak, or any OpenID Connect provider)
What you get:
- Complete control over where your data lives
- Network-level isolation — Infragnite only needs outbound access to provider APIs
- Your own authentication provider and SSO configuration
- Ability to run in air-gapped or restricted environments
Security Model
Section titled “Security Model”Authentication
Section titled “Authentication”Infragnite uses OpenID Connect (OIDC) for authentication. In the cloud version, this is managed via Auth0. Self-hosted deployments can use any OIDC-compatible provider.
All API access requires a valid JWT token. There are no shared secrets or API keys for user authentication.
Authorization
Section titled “Authorization”Access is controlled through role-based access control (RBAC) with predefined and custom roles. Permissions are scoped per organization, with workspace-level overrides planned.
Provider Credentials
Section titled “Provider Credentials”Your provider API keys and tokens are:
- Stored encrypted at rest
- Used only for API calls to the respective provider
- Never logged or exposed in the UI
- Scoped to the workspace where they were added
Service Accounts
Section titled “Service Accounts”For automation and CI/CD integration, Infragnite supports service accounts with:
- Personal access tokens with configurable expiry
- Scoped permissions matching RBAC roles
- Token management UI (create, list, revoke)
- Full audit trail of service account activity
Audit Trail
Section titled “Audit Trail”Every action in Infragnite is recorded in an immutable audit log:
- Who performed the action
- What was changed
- When it happened
- The result (success or failure)
Audit logs are filterable and exportable (CSV/JSON) for compliance reporting.
Data Isolation
Section titled “Data Isolation”In the cloud SaaS version, each organization’s data is stored in a separate database. This provides:
- Complete isolation — one organization’s queries never touch another’s data
- Independent scaling — high-traffic organizations don’t affect others
- Simplified compliance — data boundaries are clear and enforceable
- Clean offboarding — deleting an organization removes all its data completely
Self-hosted deployments are inherently single-tenant, so isolation is handled at the infrastructure level.