Deployment guide

Infisical

Overview

Infisical is an open-source, self-hosted secrets management platform and an alternative to HashiCorp Vault and Doppler. Teams use it to store, organise, share and version application secrets and configuration across organisations, projects and environments. It offers folders, secret referencing, a REST API, a CLI and SDKs, all managed through a modern web interface.

This SecureAnyCloud image runs Infisical the officially supported way: the upstream all-in-one container alongside a bundled PostgreSQL and Redis, orchestrated by Docker Compose under systemd and fronted by nginx. Every image is pinned by digest and captured into the VM, so your instance starts in seconds. Because Infisical is a secrets vault, security is enforced from first boot, before the port is reachable.

Infisical is a trademark of its respective owner. This image is produced by SecureAnyCloud and is not affiliated with, endorsed by, or sponsored by Infisical. It ships the free and open-source MIT self-hosted Community core. The enterprise features in the ee directory stay locked because no license key is ever set.

What you get:

  • Infisical v0.162.9 (the free self-hosted MIT Community core), pinned by image digest
  • A bundled PostgreSQL 16 database and a bundled Valkey 8.1 cache and job queue (the BSD-licensed, Redis-compatible data store), both pinned by image digest and reachable only inside a private Docker network, never published to a host port
  • Docker Engine (Docker CE) with Infisical published to the loopback interface only, fronted by nginx on port 80
  • infisical.service, infisical-firstboot.service and nginx.service as systemd units, enabled and active on boot
  • A unique KMS encryption key, JWT secret, database password and cache password, plus a pre-seeded super administrator, generated for each VM on first boot and never baked into the image
  • A clean, empty instance on first boot: no default account, no shipped secret, no prior data, and open self-registration disabled
  • 24/7 SecureAnyCloud support

Prerequisites

You need an active Azure subscription, an SSH key pair, and a VNet with a subnet in the target region.

Standard_B2s (2 vCPU / 4 GiB RAM) is a sensible starting size. Increase the size for larger teams and heavier API traffic.

Configure the network security group (NSG) to allow inbound 22/tcp from your management network and 80/tcp for the web interface. Also allow 443/tcp once you add TLS. Infisical serves plain HTTP on port 80, so for production, put it behind TLS with your own domain (see the final section).

Step 1 - Deploy from the Azure Marketplace

  • In the Azure portal, choose Create a resource and search the Marketplace for the SecureAnyCloud Infisical offer.
  • Select the plan, then Create.
  • On the Basics tab, pick your subscription, resource group and region, name the VM, and select Standard_B2s (or larger).
  • Choose SSH public key authentication with the admin username azureuser, and provide your public key.
  • On the Networking tab, allow inbound 22/tcp from your management network and 80/tcp for the web interface.
  • Review and create the VM. When it is running, note its public IP address.

Step 2 - Deploy from the Azure CLI

az vm image terms accept --urn sac1647283583153:infisical:default:latest
az vm create \
  --resource-group my-infisical-rg \
  --name infisical \
  --image sac1647283583153:infisical:default:latest \
  --size Standard_B2s \
  --admin-username azureuser \
  --generate-ssh-keys \
  --public-ip-sku Standard

Open the port that the web interface needs. SSH is opened by default:

az vm open-port --resource-group my-infisical-rg --name infisical --port 80 --priority 900

Step 3 - Connect to your VM

Connect over SSH. Replace <vm-ip> with your VM's public IP address:

ssh azureuser@<vm-ip>

Step 4 - Confirm the services are running

Infisical, its bundled PostgreSQL and Valkey, and nginx all start automatically on first boot. Confirm that they are active:

sudo systemctl is-active docker infisical nginx

Expected output:

active active active

The stack runs as three containers on a private Docker network. PostgreSQL and Valkey are never published to a host port. Only Infisical is published, and only to the loopback interface, with nginx in front on port 80.

Step 5 - Secure by default: the super administrator is pre-seeded

A fresh Infisical instance has no account, and the first user to sign up becomes the instance super administrator. On a public server, that is a risk: whoever reaches the sign-up page first would own your instance and every secret in it.

This image closes that gap. On first boot, before the port is reachable, it creates a unique super administrator with a per-VM password, so the instance is already claimed. The same step marks the instance initialised, so a second attempt to bootstrap it is refused. It also disables open self-registration, so nobody can create an account without an invitation.

In this locked-down state, the instance reports that it is initialised with sign-up disabled, refuses a second bootstrap attempt, denies anonymous API calls and blocks self-registration.

To confirm the lockdown yourself, attempt a second bootstrap. The instance refuses it because it is already set up:

curl -s -o /dev/null -w 'HTTP %{http_code}\n' \
  -X POST http://127.0.0.1/api/v1/admin/bootstrap \
  -H 'Content-Type: application/json' \
  -d '{"email":"someone@example.com","password":"whatever","organization":"x"}'

A healthy, locked down instance returns HTTP 400.

Read your unique credentials. They are written to a root-only file:

sudo cat /root/infisical-credentials.txt

The file holds the instance URL, the admin email (admin@infisical.local), the per-VM admin password and a per-VM machine credential (INFISICAL_CLIENT_ID and INFISICAL_CLIENT_SECRET) for the API, CLI and SDKs. Keep the file safe.

Use the machine credential for the API and CLI

First boot creates a machine identity named sac-admin-machine with the organisation Admin role. It attaches Universal Auth to the identity, the authentication method that Infisical recommends for applications and automation.

The client ID and client secret never expire on their own. Exchange them for a short-lived access token whenever you need one. A token is valid for one hour and renewable for up to 24 hours. Run this on the VM to get a token:

sudo bash -c 'set -a; . <(grep -E "^INFISICAL_CLIENT_(ID|SECRET)=" /root/infisical-credentials.txt); set +a jq -n "{clientId: env.INFISICAL_CLIENT_ID, clientSecret: env.INFISICAL_CLIENT_SECRET}" \
  | curl -s -X POST http://127.0.0.1/api/v1/auth/universal-auth/login -H "Content-Type: application/json" -d @- \
  | jq "{expiresIn, tokenType}"'

A working credential returns "expiresIn": 3600 and "tokenType": "Bearer".

From another machine, the Infisical CLI does the same with infisical login --method=universal-auth --client-id=<id> --client-secret=<secret> --domain=http://<vm-ip>. A machine identity only sees the projects it is a member of. Add it to a project under Project Settings, Access Control, Machine Identities before it reads that project's secrets.

To rotate the client secret, sign in as the administrator and open Organization Settings, Access Control, Identities, sac-admin-machine. Under Universal Auth, create a new client secret. Update your applications to use it, then revoke the old secret from the same page. When a token expires, log in again with the client ID and secret to get a new one.

If you do not need API access from this identity, reduce its role or delete it. For production, create one identity per application with only the access it needs.

Step 6 - Sign in to Infisical

Open http://<vm-ip>/ in your browser. The Infisical login screen appears, because there is no anonymous access. Sign in with the admin email and the password from the credentials file.

Step 7 - Explore the organization

After you sign in, you land on the organization overview, the home of your security toolkit. Secrets Management is where your projects live. The sidebar also gives you Access Control, Audit Logs and settings.

A badge shows that this is the free self-hosted edition, running the version pinned into your image.

Step 8 - Manage secrets in a project

Open Secrets Management, create a project, and open it to reach the secrets view. A project groups secrets by environment (Development, Staging and Production by default) and by folder path.

Select Add Secret to add a secret, or import a whole .env file at once. Values are stored encrypted and shown masked until you choose to reveal them. Your apps and pipelines pull the values through the Infisical CLI, API or SDKs instead of hard-coding them.

Step 9 - Control who has access

Each project has its own Access Control page, where you manage users, machine identities, groups, service tokens and roles.

Open self-registration is disabled on this instance, so people join by invitation only. You assign each person a project role. Machine identities give your applications and CI pipelines their own scoped, revocable credentials.

Step 10 - Check the stack health from the command line

Infisical exposes an unauthenticated liveness endpoint that reports whether the instance is up and its cache is reachable. It is useful for monitoring:

curl -s http://127.0.0.1/api/status

A healthy stack reports "message": "Ok" along with the instance configuration. For example, the output shows that the Redis-protocol cache, served by Valkey, is configured.

Step 11 - Invite your team and configure email

Open self-registration is disabled, so add colleagues by invitation. Sign in as the administrator and open Organization Settings, Members.

To send email invitations and enable multi-factor authentication, configure SMTP. Set the SMTP_HOST, SMTP_PORT, SMTP_USERNAME, SMTP_PASSWORD and SMTP_FROM_ADDRESS values in /etc/infisical/infisical.env, then restart the stack with sudo systemctl restart infisical. See the Infisical documentation for the full list of SMTP settings.

Step 12 - Production: your own domain with TLS

Infisical serves plain HTTP on port 80. For production, point a DNS record at the VM, put Infisical behind TLS, and set the site URL to your https domain so that links and cookies use the right origin.

A common approach is to add a certificate to nginx with Certbot:

sudo apt-get install -y certbot python3-certbot-nginx
sudo certbot --nginx -d secrets.example.com

Then, in /etc/infisical/infisical.env, change SITE_URL to https://secrets.example.com and set HTTPS_ENABLED=true. Restart the stack with sudo systemctl restart infisical. See the Infisical documentation for the full production checklist.

Support

Every SecureAnyCloud image includes 24/7 support. For questions about deploying or operating Infisical on Azure, contact the SecureAnyCloud team through the Azure Marketplace listing or at secureanycloud.com.

Deploy on Azure

Launch Infisical on Ubuntu 24.04 LTS on Azure with 24/7 support from SecureAnyCloud.

View this image

Need Help?

Our support team is available 24/7.

sales@secureanycloud.com

Deploy on Azure