Sign in Безкоштовно назавжди Get started

Infrastructure

Zero secrets in config.
Zero secrets in logs.

Every platform, every orchestrator, every CI runner. The proxy works with anything that makes HTTP calls. The CLI works with anything that can shell out. If your system is older than your career, it still works.

The proxy is the universal integration.

If your workload makes HTTPS calls, the Clavitor proxy injects credentials at the network layer. No code changes. No SDKs. No secrets in environment variables, config files, or logs. Set HTTPS_PROXY and your existing code works unchanged — the proxy resolves clavitor:// references in request headers before the request leaves the machine.

$ export HTTPS_PROXY=http://localhost:1983
$ curl -H "Authorization: Bearer clavitor://Stripe API/key" \
  https://api.stripe.com/v1/charges
# The agent never sees sk_live_... — only clavitor:// appears in logs

Containers

Docker and Kubernetes

Docker Compose

Run the Clavitor proxy on the host and point your containers at it. Credentials are injected transparently into outbound requests — no secrets in environment variables, no secrets baked into images.

# On the Docker host
$ clavitor-proxy serve &
# docker-compose.yml — containers route through the host-mode proxy
services:
  app:
    environment:
      - HTTPS_PROXY=http://host.docker.internal:1983
    extra_hosts:
      - "host.docker.internal:host-gateway"

Or use render to resolve a config template at startup:

$ clavitor-cli render app.config.template.yml | docker compose -f - up

Kubernetes

Create secrets from the vault without hardcoding values in manifests:

$ kubectl create secret generic app-secrets \
  --from-literal=db-pass="$(clavitor-cli get 'Production DB' --field password)" \
  --from-literal=api-key="$(clavitor-cli get 'Stripe API' --field key)"

For runtime credential injection, deploy the proxy as a sidecar container in your pod. Application containers set HTTPS_PROXY to the sidecar. Credentials are resolved per-request, never stored in etcd.

IaC

Terraform, Ansible, Pulumi

Terraform

Resolve credentials into the provider environment before terraform apply. The AWS provider reads its credentials from standard environment variables — Clavitor populates them inline, the .tf file mentions no secret.

$ export AWS_ACCESS_KEY_ID=$(clavitor-cli get "AWS Root" --field access_key_id)
$ export AWS_SECRET_ACCESS_KEY=$(clavitor-cli get "AWS Root" --field secret_key)
$ terraform apply

The provider "aws" {} block stays empty in your code. Same pattern works for any Terraform provider that supports env-var credentials (which is most of them).

Ansible

- name: Get database password
  command: clavitor-cli get "Production DB" --field password
  register: db_pass
  no_log: true

- name: Configure app
  template:
    src: app.conf.j2
  vars:
    db_password: "{{ db_pass.stdout }}"

Pulumi

import { execSync } from 'child_process';
const dbPass = execSync('clavitor-cli get "Production DB" --field password').toString().trim();
new aws.rds.Instance("db", { masterPassword: new pulumi.secret(dbPass) });

CI/CD

GitHub Actions, GitLab CI, Jenkins

The token is piped on stdin in every example below — keeping it out of argv so it does not appear in /proc/<pid>/cmdline or build logs.

GitHub Actions

- name: Deploy
  env:
    CLAVITOR_TOKEN: ${{ secrets.CLAVITOR_TOKEN }}
  run: |
    echo "$CLAVITOR_TOKEN" | clavitor-cli init
    kubectl create secret generic app-secrets \
      --from-literal=api-key="$(clavitor-cli get 'Deploy Token' --field key)" \
      --dry-run=client -o yaml | kubectl apply -f -

GitLab CI

deploy:
  script:
    - echo "$CLAVITOR_TOKEN" | clavitor-cli init
    - clavitor-cli get "Deploy Key" --field private_key | ssh-add -
    - ssh deploy@production "systemctl restart app"

Jenkins

pipeline {
  stages {
    stage('Deploy') {
      steps {
        sh 'echo "$CLAVITOR_TOKEN" | clavitor-cli init'
        sh 'clavitor-cli get "Deploy Key" --field private_key | ssh-add -'
        sh 'ssh deploy@production "systemctl restart app"'
      }
    }
  }
}

SSH

Vault-stored keys

$ clavitor-cli get "Deploy Key" --field private_key | ssh-add -
$ ssh deploy@production

The private key is piped directly into ssh-add. It never touches disk, never appears in shell history, and is cleared from the agent when the session ends.

Legacy systems

If it makes an HTTP call, it works.

The proxy doesn't care what language made the request. COBOL, FORTRAN, Perl, Visual Basic, a 30-year-old batch job — if the process makes an HTTPS request, the proxy intercepts it, resolves the clavitor:// reference, and injects the real credential. No code changes required.

For systems that can't make HTTP calls, use clavitor-cli render to resolve a config template before the process starts. The template is safe to store anywhere. The resolved output goes to stdin or a temporary file with restricted permissions.

# Resolve credentials before the batch job starts
$ clavitor-cli render db-connect.template.cfg > /tmp/db-connect.cfg
$ chmod 600 /tmp/db-connect.cfg
$ /opt/legacy/batch-job --config /tmp/db-connect.cfg
$ rm /tmp/db-connect.cfg

The pattern is always the same.

CLI for scripts and pipelines. Proxy for HTTP workloads. Render for config files. Every secret resolved at runtime, never stored.