Manage Django Secrets With Infisical

Use Infisical, an open-source secrets manager, for Django: organize projects and environments, inject secrets with infisical run, authenticate servers and CI with machine identities, sync to Kubernetes and platforms, and self-host or use Infisical Cloud.

Problem statement

You want a central place for Django secrets with environments, access control, and audit history, but prefer an open-source tool you can self-host, or you need features like secret referencing and point-in-time recovery of secret values. Infisical provides a web UI, CLI, SDKs, and Kubernetes integration. Like other secrets managers, it can inject variables into Django processes so settings code stays unchanged.

Infisical for DjangoProjectdev, staging, prodMachine identityservers, CIinfisical runenv injectionDjangoos.environInfisical supplies environment variables; Django reads them as usual.
  1. Create a project with dev, staging, and prod environments and add the Django variables.
  2. Locally: infisical login, infisical init, then infisical run --env=dev -- python manage.py runserver.
  3. For servers and CI, create a machine identity (universal auth client ID and secret) with access to one environment.
  4. On servers, start Gunicorn with infisical run --env=prod -- gunicorn ... after logging in with the machine identity.
  5. In Kubernetes, use the Infisical operator (or External Secrets Operator) to sync secrets into a Kubernetes Secret.

Step-by-step solution

1. Set up the project

In Infisical Cloud or your self-hosted instance, create a project for the Django app. Add secrets to each environment, optionally in folders (/web, /worker). Secret references let one value reuse another, for example building DATABASE_URL from separate host and password secrets.

2. Local development

infisical login
infisical init                     # links this directory to the project
infisical run --env=dev -- python manage.py runserver

Developers authenticate as themselves, and access can be granted per environment. There is no .env file to share or leak.

who authenticates howAuth methodScopeDeveloper laptopuser logindev, by roleVM or containeruniversal auth identityprod, read onlyGitHub ActionsOIDC identityper workflowKubernetesk8s auth / operatornamespaceMachine identities replace long-lived shared tokensdjango-deployment.com
OIDC identities avoid storing any Infisical secret in CI.

3. Servers and containers

Create a machine identity with universal auth and grant it read access to prod. On the server, store its client ID and secret as the only local secrets:

export INFISICAL_TOKEN=$(infisical login --method=universal-auth \
  --client-id="$INFISICAL_CLIENT_ID" --client-secret="$INFISICAL_CLIENT_SECRET" --silent --plain)
exec infisical run --env=prod --projectId="$INFISICAL_PROJECT_ID" -- \
  gunicorn config.wsgi --bind 0.0.0.0:8000 --workers 3

Use this as a container entrypoint or a systemd ExecStart wrapper script. For self-hosted instances, set INFISICAL_API_URL (or --domain) to your server.

4. CI and Kubernetes

In GitHub Actions, use an OIDC machine identity so the workflow authenticates without stored secrets, then run tests or migrations with infisical run. In Kubernetes, the Infisical operator watches an InfisicalSecret resource and creates a Kubernetes Secret, optionally restarting Deployments when values change. External Secrets Operator also has an Infisical provider if you already use it.

5. Self-host or cloud

Infisical can run self-hosted with Docker or Helm, backed by PostgreSQL and Redis. Self-hosting keeps secrets on your infrastructure but makes you responsible for the instance's availability, backups, and upgrades. If Infisical is down, processes using infisical run cannot start, so plan for high availability or a synced fallback (Kubernetes Secrets keep the last synced values).

where should Infisical run?What matters most?little ops capacityInfisical Cloudmanaged uptimedata must stay in-houseSelf-hostHelm or Dockeralready run VaultKeep Vaultavoid two systemsA secrets manager must be more available than the apps that depend on itdjango-deployment.com
Back up a self-hosted instance like any production database.

Explanation

Infisical encrypts secrets, organizes them by project, environment, and path, and controls access through user roles and machine identities. Delivery to Django is through environment variables, either injected at process start by the CLI or synced into platform-native stores. The design mirrors other managers; its distinguishing points are being open source and self-hostable, with modern machine authentication methods.

Edge cases / notes

  • Restart for changes. Changed secrets apply when processes restart; the Kubernetes operator can trigger rolling restarts.
  • Secret sprawl. Use folders and naming conventions so web, worker, and job settings do not drift.
  • Local overrides. infisical run lets local environment variables override fetched ones when configured; be careful not to mask production values in scripts.

Next steps

FAQ

Is Infisical free?

The core is open source and self-hostable; Infisical Cloud has free and paid tiers.

Do I need to change Django settings?

No. Infisical injects environment variables, which settings read as before.

How do servers authenticate?

With machine identities, such as universal auth credentials or cloud and OIDC identities.

What if Infisical is unavailable?

Processes that fetch secrets at start cannot start. Use high availability or synced fallbacks like Kubernetes Secrets.

Keep going