Skip to content

How to store application secrets and inject them at runtime

How-to · Updated Sep 2026

Coming from another cloud?

▸AWS·Secrets Manager

This Quake AI feature maps to AWS’s Secrets Manager.

▸Azure·KEY Vault

This Quake AI feature maps to Azure’s KEY Vault.

▸DigitalOcean·APP Platform ENV Vars

This Quake AI feature maps to DigitalOcean’s APP Platform ENV Vars.

▸Google Cloud·Secret Manager

This Quake AI feature maps to Google Cloud’s Secret Manager.

How to store application secrets and inject them at runtime

Keep database passwords, API tokens, and signing keys out of git by injecting them at deploy time. Quake AI does not run a managed secrets manager like AWS Secrets Manager. Use CI secrets plus environment files on VMs, Kubernetes Secret objects on clusters, or self-hosted Vault for team-scale rotation.

Choose a pattern#

WorkloadPatternRotation
VM + systemd serviceCI secret → SSH → /etc/myapp/envRedeploy from CI with new values
VM + DockerCI secret → docker run -e or env fileRedeploy container
KubernetesSecret + envFrom or mounted volumekubectl apply or Helm values from CI
Many services / teamsHashiCorp Vault on a Quake AI VMVault policies and dynamic secrets

VM: inject with CI and systemd#

  1. Store secrets in GitHub Actions or GitLab CI variables (masked).
  2. During deploy (application CI/CD), write a root-owned env file:
bash
ssh "$DEPLOY_USER@$DEPLOY_HOST" 'sudo install -D -m 600 /dev/stdin /etc/myapp/env' <<EOF
DATABASE_URL=${{ secrets.DATABASE_URL }}
API_KEY=${{ secrets.API_KEY }}
EOF

The -D flag creates /etc/myapp if it does not exist, so this step succeeds on a fresh VM without a separate mkdir.

  1. Reference the file in the unit file:
ini
[Service]
EnvironmentFile=/etc/myapp/env
  1. Reload systemd and restart the service.

Never commit /etc/myapp/env to git or bake it into a custom image.

Kubernetes: Secret and deployment#

bash
kubectl create secret generic myapp-secrets \
  --from-literal=DATABASE_URL="$DATABASE_URL" \
  --from-literal=API_KEY="$API_KEY" \
  -n my-namespace
YAML
envFrom:
  - secretRef:
      name: myapp-secrets

For private registry credentials, use image pull secrets.

Self-hosted Vault (advanced)#

Run Vault on a dedicated instance with persistent block storage. Applications authenticate with AppRole or Kubernetes auth. This pattern suits teams that already operate Vault; it is more moving parts than CI-injected env files.

Rotate secrets#

  1. Generate a new credential at the provider (database, API vendor).
  2. Update CI variables.
  3. Redeploy VMs or roll Kubernetes Deployments.
  4. Revoke the old credential after traffic stabilizes.

See also#

Usage Guidelines

The sample code, software libraries, command line tools, proofs of concept, templates, and other related technology on this page (including any of the foregoing that is provided by Quake AI personnel) is provided to you as Quake AI Content under the Quake AI Customer Agreement, or the relevant written agreement between you and Quake AI (whichever applies). Do not use this Quake AI Content in your production accounts, or on production or other critical data. You are responsible for testing, securing, and optimizing the Quake AI Content (such as sample code) as appropriate for production grade use based on your specific quality control practices and standards. Deploying Quake AI Content may incur Quake AI charges for creating or using Quake AI chargeable resources, such as running Compute instances or storing data in Object Storage. Your use is also subject to the Acceptable Use Policy.

For the full policy, see Usage Guidelines.

Last validated: 08.09.2026

Was this page helpful?