Do I need a domain name?

Yes, and it is not negotiable for this app. `SITE_URL` is baked into the web application, the CLI login flow and team invitation links, and secrets in transit must be protected by TLS. Point a record such as `secrets.example.com` at your VPS before deploying; certificates are issued and renewed automatically.

Who can read my secrets on a self-hosted instance?

Only the identities you grant access to. The vault is encrypted at rest with an `ENCRYPTION_KEY` generated on your own VPS at deployment time and stored nowhere else, so neither Infisical the company nor your hosting provider can decrypt the contents. Telemetry is disabled in the shipped configuration, and nothing leaves the machine except the responses to your own API calls.

What happens if I lose the encryption key?

The vault becomes unreadable — that is the point of holding the key yourself, and it is the single most important thing to back up. Store `ENCRYPTION_KEY` and `AUTH_SECRET` somewhere outside the VPS (an offline password manager, a sealed envelope, your own recovery procedure) before you start putting real credentials in. A backup of the PostgreSQL volume without the encryption key restores nothing.

How do my applications and pipelines authenticate?

Humans log in through the web UI or `infisical login`. Machines — CI runners, containers, servers — use a machine identity: a client ID and client secret that you create in the dashboard, scope to a single project and environment, and revoke independently of any person's account. That way a leaked CI token never exposes production, and an employee leaving does not break your deployments.

How much RAM does it need, and how do I back it up?

2 GB is a sensible baseline for the three containers (Node.js application, PostgreSQL 14, Redis). The state that matters lives in the `infisical_db` volume, with uploaded files in `infisical_data`; a `pg_dump` of the database plus a copy of `ENCRYPTION_KEY` and `AUTH_SECRET` kept apart from it is a complete, restorable backup.

Harden infrastructure security.

Infisical

Self-hosted secrets manager — one encrypted vault for API keys, env vars and certificates, injected into your apps and CI/CD pipelines instead of copied into `.env` files.

2 GB RAM 2 vCPU Port 8080 Available

Source code

Tech stack

DockerNode.jsPostgreSQL 14Redis

Minimum RAM2 GB

Minimum CPU2 vCPU

Default port8080

Compatible OSubuntu-24.04

Infisical is an open-source secrets management platform whose core is MIT-licensed. It replaces the `.env` files passed around on Slack, the credentials hard-coded in a CI configuration and the copy of production keys sitting on a developer laptop with a single encrypted vault that applications read at startup — through a CLI, an SDK or a Kubernetes operator.

Secrets are organised by project and by environment (development, staging, production), each with its own access rules. Every change is versioned, so you can see who rotated which key and roll a project back to any earlier point; an audit log records every read and write. Machine identities give a CI pipeline or a container its own credentials, separate from any human account, and can be revoked without touching anyone's login.

On a ServOrbit VPS, Infisical runs as three containers — `infisical/infisical` for the application, `postgres:14-alpine` for storage and `redis:alpine` for caching and queues. Telemetry is disabled in the deployed configuration, and the encryption key never leaves your machine: the vault is encrypted at rest with a key generated on your own VPS, which means neither Infisical the company nor ServOrbit can read your secrets.

Key features

One vault for every kind of secret: API keys, database URLs, environment variables, tokens, SSH keys and certificates, all encrypted at rest.

Projects and environments: separate development, staging and production values behind their own access rules, with secret referencing and imports to avoid duplicating shared values.

Inject secrets at runtime instead of writing files: `infisical run -- npm start` fetches the right environment's values and passes them to your process as env vars.

SDKs for Node.js, Python, Go, Java, .NET, Ruby and Rust, plus a Kubernetes operator that syncs secrets into native `Secret` objects.

CI/CD integrations: GitHub Actions, GitLab CI, Jenkins, Terraform and Docker — pipelines authenticate as a machine identity, not as a human account.

Versioning and point-in-time recovery: every write is a new version, so you can diff, audit and roll a whole project back to any earlier state.

Audit log and RBAC: every read, write and rotation is recorded with its author; roles control who sees production values and who only sees development.

Secret scanning: a pre-commit hook and repository scanner that catch credentials before they are pushed to Git.

When to use this solution?

1

Kill the `.env` file passed around on Slack

Instead of mailing an env file to each new developer and hoping the copies stay in sync, everyone runs `infisical run -- npm run dev` and gets the current development values. Rotating a key becomes one edit in the vault rather than a message asking six people to update their local file — and nobody ends up holding production credentials they never needed.

2

Credentials for CI/CD pipelines

Give each pipeline its own machine identity with read-only access to exactly the environment it deploys. The pipeline pulls secrets at run time rather than storing them as repository variables, so revoking a compromised runner is a single revocation in the vault — and every fetch is in the audit log with a timestamp.

3

Traceability for an audit

When you have to demonstrate who could reach production credentials and when they were last rotated, the audit log and version history answer it directly: each secret carries its full change history with authors and dates, and RBAC shows which roles can read which environment. That is the evidence a SOC 2 or ISO 27001 reviewer asks for, without reconstructing it from memory.

Deploy Infisical on your VPS

Guide optimized for ServOrbit Cloud VPS.

01

Order a ServOrbit VPS

Plan for 2 GB of RAM: the Node.js application, PostgreSQL and Redis run side by side, and the API is on the critical path of every deployment you make. A VPS dedicated to Infisical — rather than one shared with heavy workloads — keeps secret retrieval fast and isolates the vault from your other applications.

02

Point a domain at the VPS

Infisical requires a domain: SITE_URL is embedded in the web app, in the CLI login flow and in the invitation links sent to your team, and secrets must never travel over plain HTTP. Create an A record such as secrets.example.com pointing to your VPS IP — TLS is issued and renewed automatically after deployment.

03

One-click deploy from the marketplace

Open your ServOrbit dashboard → Marketplace → Security → Infisical → Deploy. Docker pulls the three images, generates ENCRYPTION_KEY and AUTH_SECRET, runs the database migrations and serves the web UI on port 8080 behind the HTTPS vhost. Telemetry is switched off in the shipped configuration.

04

Create your organisation and first project

Open your domain in a browser and register the first account — it becomes the organisation administrator. Create a project, then the environments you actually use (development, staging, production), and paste in your existing secrets or import an .env file directly from the web UI. Invite your team and assign each member a role per environment.

05

Connect your applications

Install the CLI (brew install infisical/get-cli/infisical or the apt/npm package), run infisical login against your own domain, then infisical init in the project directory. Your app now starts with infisical run -- npm start and receives its secrets as environment variables. For CI, create a machine identity in the dashboard and authenticate the pipeline with its client ID and secret instead of a personal account.

Frequently asked questions

The `.env` files copied between laptops, the credentials pasted into a CI settings page, and the shared password-manager note that everyone forgets to update. Applications fetch their configuration from a single vault at startup, so there is exactly one place where a key lives, one place to rotate it, and a log of everyone who read it. It is the self-hosted equivalent of Doppler or AWS Secrets Manager, and an alternative to HashiCorp Vault with a much shorter setup.