> ## Documentation Index
> Fetch the complete documentation index at: https://infisical.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Programmatic provisioning

> Learn how to provision and configure Infisical instances programmatically without UI interaction

Infisical's Automated Bootstrapping feature enables you to provision and configure an Infisical instance without using the UI, allowing for complete automation through static configuration files, API calls, or CLI commands. This is especially valuable for enterprise environments where automated deployment and infrastructure-as-code practices are essential.

The bootstrapping workflow automates creating an admin user account, initializing an organization for the entire instance, establishing an **instance admin machine identity** with full administrative permissions, and returning the machine identity credentials for further automation.

## Prerequisites

* An Infisical instance launched with all required configuration variables
* Access to the Infisical CLI or the ability to make API calls to the instance
* Network connectivity to the Infisical instance

## Key concepts

* **Instance Initialization**: Infisical requires [configuration variables](https://infisical.com/docs/self-hosting/configuration/envars.md) to be set during launch, after which the bootstrap process can be triggered.
* **Instance Admin Machine Identity**: The bootstrapping process creates a machine identity with instance-level admin privileges, which can be used to programmatically manage all aspects of the Infisical instance. It appears under **Resource Overview > Machine Identities** in the [Server Console](https://infisical.com/docs/documentation/platform/admin-panel/server-admin.md).

  ![Instance Admin Identity](https://mintlify.s3.us-west-1.amazonaws.com/infisical/images/self-hosting/guides/automated-bootstrapping/identity-instance-admin.png)
* **Token Auth**: The instance admin machine identity uses [Token Auth](https://infisical.com/docs/documentation/platform/identities/token-auth.md), providing a JWT token that can be used directly to make authenticated requests to the Infisical API.

## Bootstrap methods

You can bootstrap an Infisical instance using the API, CLI, or Helm chart.

> [tab] Using the API
>
> Make a POST request to the bootstrap endpoint:
>
> ```
> POST: http://your-infisical-instance.com/api/v1/admin/bootstrap
> {
>     "email": "admin@example.com",
>     "password": "your-secure-password",
>     "organization": "your-org-name"
> }
> ```
>
> Example using curl:
>
> ```bash theme={"dark"}
> curl -X POST \
>   -H "Content-Type: application/json" \
>   -d '{"email":"admin@example.com","password":"your-secure-password","organization":"your-org-name"}' \
>   http://your-infisical-instance.com/api/v1/admin/bootstrap
> ```
>
> ### API response structure
>
> The bootstrap process returns a JSON response with details about the created user, organization, and machine identity:
>
> ```json theme={"dark"}
> {
>   "identity": {
>     "credentials": {
>       "token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpZGVudGl0eUlkIjoiZGIyMjQ3OTItZWQxOC00Mjc3LTlkYWUtNTdlNzUyMzE1ODU0IiwiaWRlbnRpdHlBY2Nlc3NUb2tlbklkIjoiZmVkZmZmMGEtYmU3Yy00NjViLWEwZWEtZjM5OTNjMTg4OGRlIiwiYXV0aFRva2VuVHlwZSI6ImlkZW50aXR5QWNjZXNzVG9rZW4iLCJpYXQiOjE3NDIzMjI0ODl9.mqcZZqIFqER1e9ubrQXp8FbzGYi8nqqZwfMvz09g-8Y"
>     },
>     "id": "db224792-ed18-4277-9dae-57e752315854",
>     "name": "Instance Admin Identity"
>   },
>   "message": "Successfully bootstrapped instance",
>   "organization": {
>     "id": "b56bece0-42f5-4262-b25e-be7bf5f84957",
>     "name": "dog",
>     "slug": "dog-v-e5l"
>   },
>   "user": {
>     "email": "admin@example.com",
>     "firstName": "Admin",
>     "id": "a418f355-c8da-453c-bbc8-6c07208eeb3c",
>     "lastName": "User",
>     "superAdmin": true,
>     "username": "admin@example.com"
>   }
> }
> ```

> [tab] Using the CLI
>
> Use the [Infisical CLI](https://infisical.com/docs/cli/reference.md#bootstrap) to bootstrap the instance and extract the token for immediate use in automation:
>
> ```bash theme={"dark"}
> infisical bootstrap --domain="http://localhost:8080" --email="admin@example.com" --password="your-secure-password" --organization="your-org-name" | jq ".identity.credentials.token"
> ```
>
> This example command pipes the output through `jq` to extract only the machine identity token, making it easy to capture and use directly in automation scripts or export as an environment variable for tools like Terraform.
>
> ### API response structure
>
> The bootstrap process returns a JSON response with details about the created user, organization, and machine identity:
>
> ```json theme={"dark"}
> {
>   "identity": {
>     "credentials": {
>       "token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpZGVudGl0eUlkIjoiZGIyMjQ3OTItZWQxOC00Mjc3LTlkYWUtNTdlNzUyMzE1ODU0IiwiaWRlbnRpdHlBY2Nlc3NUb2tlbklkIjoiZmVkZmZmMGEtYmU3Yy00NjViLWEwZWEtZjM5OTNjMTg4OGRlIiwiYXV0aFRva2VuVHlwZSI6ImlkZW50aXR5QWNjZXNzVG9rZW4iLCJpYXQiOjE3NDIzMjI0ODl9.mqcZZqIFqER1e9ubrQXp8FbzGYi8nqqZwfMvz09g-8Y"
>     },
>     "id": "db224792-ed18-4277-9dae-57e752315854",
>     "name": "Instance Admin Identity"
>   },
>   "message": "Successfully bootstrapped instance",
>   "organization": {
>     "id": "b56bece0-42f5-4262-b25e-be7bf5f84957",
>     "name": "dog",
>     "slug": "dog-v-e5l"
>   },
>   "user": {
>     "email": "admin@example.com",
>     "firstName": "Admin",
>     "id": "a418f355-c8da-453c-bbc8-6c07208eeb3c",
>     "lastName": "User",
>     "superAdmin": true,
>     "username": "admin@example.com"
>   }
> }
> ```

> [tab] Helm Chart
>
> When deploying Infisical using the official [Helm chart](https://infisical.com/docs/self-hosting/deployment-options/kubernetes-helm.md), you can enable automatic bootstrapping that runs as part of the deployment process. This eliminates the need to manually bootstrap the instance after deployment.
>
> The bootstrapping process automatically generates a Kubernetes secret containing the instance admin token, which can then be referenced by Crossplane providers, Terraform operators, or other automation systems for further infrastructure provisioning and configuration.
>
> ### Configuration
>
> Enable auto bootstrapping in your Helm values by setting `autoBootstrap.enabled: true` and providing the necessary configuration:
>
> ```yaml theme={"dark"}
> autoBootstrap:
>   enabled: true
>   organization: "My Organization"
>   secretTemplate: '{"data":{"token":"{{.Identity.Credentials.Token}}"}}'
>
>   secretDestination:
>     name: "infisical-bootstrap-secret"
>     namespace: "" # leave empty to use the release namespace
>
>   credentialSecret:
>     name: "infisical-bootstrap-credentials"
> ```
>
> > [!WARNING]
> >
> > Chart versions before 1.11.0 shipped `secretDestination.namespace` as the literal string
> > `default`, so the fallback to the release namespace never applied. Those releases wrote the
> > instance admin token to the `default` namespace and still reported a successful install.
> >
> > This default applies to future bootstrap runs only. Upgrading an existing release does not move
> > the secret that is already there, so follow the migration steps below.
>
> You'll also need to create a secret containing the bootstrap credentials before deployment. The secret must contain `INFISICAL_ADMIN_EMAIL` and `INFISICAL_ADMIN_PASSWORD` keys:
>
> ```bash theme={"dark"}
> kubectl create secret generic infisical-bootstrap-credentials \
>   --from-literal=INFISICAL_ADMIN_EMAIL="admin@example.com" \
>   --from-literal=INFISICAL_ADMIN_PASSWORD="your-secure-password" \
>   --namespace=release-namespace
> ```
>
> ### Migrating from chart versions before 1.11.0
>
> Upgrading moves the bootstrap Role and RoleBinding to the release namespace, but it leaves the
> secret itself in `default`. The bootstrap job is a post-install hook, and an instance can be
> bootstrapped only once, so the job neither re-runs on upgrade nor can reissue the token. Until
> you migrate, the instance admin token stays readable in `default` while your automation looks for
> it in the release namespace.
>
> Copy the secret into the release namespace, keeping whatever keys your `secretTemplate` produced:
>
> ```bash theme={"dark"}
> release_namespace=<your-release-namespace>
>
> kubectl get secret infisical-bootstrap-secret -n default -o json \
>   | jq 'del(.metadata.namespace, .metadata.uid, .metadata.resourceVersion,
>             .metadata.creationTimestamp, .metadata.managedFields, .metadata.ownerReferences)' \
>   | kubectl apply -n "$release_namespace" -f -
> ```
>
> Confirm the copy, then remove the original:
>
> ```bash theme={"dark"}
> kubectl get secret infisical-bootstrap-secret -n "$release_namespace"
> kubectl delete secret infisical-bootstrap-secret -n default
> ```
>
> The token was readable by anything with secret access in `default` for as long as it sat there,
> so treat it as exposed and rotate the root identity credentials after you migrate.
>
> ### How it works
>
> The Helm chart auto bootstrap feature:
>
> 1. **Post-Install Hook**: Runs automatically after the main Infisical deployment is complete
> 2. **Readiness Check**: Uses an init container with curl to wait for Infisical to be ready by polling the `/api/status` endpoint
> 3. **Bootstrap Execution**: Uses the Infisical CLI to bootstrap the instance
> 4. **Kubernetes Secret Creation**: Creates a Kubernetes secret directly via the Kubernetes API using the rendered template
> 5. **RBAC**: Automatically configures the necessary permissions (`get`, `create`, `update` on secrets) for the bootstrap job
>
> ### Template system
>
> The `secretTemplate` field allows you to customize the data section of the created Kubernetes secret. The template has access to the full bootstrap response with the following available data fields:
>
> * `{{ .Identity.Credentials.Token }}`: The admin machine identity token
> * `{{ .Identity.ID }}`: The identity ID
> * `{{ .Identity.Name }}`: The identity name
> * `{{ .Organization.ID }}`: The organization ID
> * `{{ .Organization.Name }}`: The organization name
> * `{{ .Organization.Slug }}`: The organization slug
> * `{{ .User.Email }}`: The admin user email
> * `{{ .User.ID }}`: The admin user ID
> * `{{ .User.FirstName }}`: The admin user first name
> * `{{ .User.LastName }}`: The admin user last name
>
> The template also supports the `encodeBase64` function for base64 encoding values.
>
> Example template for storing multiple values:
>
> ```yaml theme={"dark"}
> secretTemplate: |
>   {
>     "data": {
>       "infisical_token": "{{ .Identity.Credentials.Token }}",
>       "admin_email": "{{ .User.Email }}",
>       "organization": "{{ .Organization.Name }}"
>     }
>   }
> ```
>
> ### Benefits
>
> * **Zero-Touch Deployment**: Complete Infisical setup without manual intervention
> * **Infrastructure as Code**: Bootstrap configuration is versioned with your Helm values
> * **Secure Token Storage**: Admin identity credentials are immediately stored in Kubernetes secrets
> * **Integration Ready**: The created secret can be referenced by other applications or automation tools
>
> ### Security considerations
>
> * The bootstrap job requires permissions to create secrets in the specified namespace
> * Bootstrap credentials should be stored securely and rotated regularly
> * The generated admin token has full instance privileges and should be protected accordingly
> * Consider using Kubernetes RBAC to restrict access to the generated secret

## Using the instance admin machine identity token

The bootstrap process automatically creates a machine identity with Token Auth configured. The returned token has instance-level admin privileges (the highest level of access) and should be treated with the same security considerations as a root credential.

The token enables full programmatic control of your Infisical instance and can be used in the following ways:

### 1. Infrastructure automation

Store the token securely for use with infrastructure automation tools. Due to the sensitive nature of this token, ensure it's protected using appropriate secret management practices:

#### Kubernetes secret (with appropriate RBAC restrictions)

```yaml theme={"dark"}
apiVersion: v1
kind: Secret
metadata:
  name: infisical-admin-credentials
type: Opaque
data:
  token: <base64-encoded-token>
```

#### Environment variable for Terraform

```bash theme={"dark"}
export INFISICAL_TOKEN=your-access-token
terraform apply
```

### 2. Programmatic resource management

Use the token to authenticate API calls for creating and managing Infisical resources. The token works exactly like any other Token Auth access token in the Infisical API:

```bash theme={"dark"}
curl -X POST \
  -H "Authorization: Bearer ${INFISICAL_TOKEN}" \
  -H "Content-Type: application/json" \
  -d '{
    "projectName": "New Project",
    "projectDescription": "A project created via API",
    "slug": "new-project-slug",
    "template": "default",
    "type": "secret-manager"
  }' \
  https://your-infisical-instance.com/api/v1/projects
```

## Important notes

* **Security Warning**: The instance admin machine identity has the highest level of privileges in your Infisical deployment. The token should be treated with the utmost security and handled like a root credential. Unauthorized access to this token could compromise your entire Infisical instance.
* Security controls prevent privilege escalation: instance admin identities can't be managed by non-instance admin users and identities
* The instance admin permission of the generated identity can be revoked later in the server admin panel if needed
* The generated admin user account can still be used for UI access if needed, or can be removed if you prefer to manage everything through the machine identity
* This process is designed to work with future Crossplane providers and the existing Terraform provider for full infrastructure-as-code capabilities
* All necessary configuration variables should be set during the initial launch of the Infisical instance


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.