Developer help

How it works

Your secrets live in projects (for example shop) with one environment each for dev, staging and production. Scripts and pipelines read one environment at a time.

• On your computer: use the ssm command line tool.
• In CI and the cloud: use an SDK. The server sends only encrypted data; it is decrypted inside your job.

Command line (ssm)

Download ssm from the Download page. Then join your vault like a new device:

ssm login "<server link>"     # the link is in the app: Settings → Add another device
# approve the request on your phone, then set a password for this computer

Read secrets:

ssm unlock                      # stays unlocked for 15 minutes
ssm list                        # item names
ssm get "GitHub"                # the password
ssm get "GitHub" --field username
ssm totp "GitHub"               # the current 2FA code
ssm lock

Run a program with an environment's secrets as environment variables. Nothing is written to disk:

ssm run --project shop --env production -- npm start
ssm run --project shop --env dev -- python manage.py runserver

Lost every device? ssm login "<server link>" --recover uses your Emergency Kit.

Give a pipeline access

1. In the app, open Settings → CI and cloud access and choose GitHub, GitLab, AWS, Azure or GCP.
2. Pick the project and environment it may read.
3. The app shows the settings to copy: server URL, server ID, pin, environment ID and, for GitHub and GitLab, a CI key.
4. Store the CI key as a secret in your CI system (for GitHub: repository secret SSM_CI_KEY). Never commit it.

Each grant reads one environment only, and you can revoke it in the app at any time. A revoked grant stops working within 5 minutes.

GitHub Actions

Use any SDK inside a workflow step. For example, with Python:

permissions:
  id-token: write   # lets the job prove who it is
  contents: read
env:
  SSM_URL: https://vault.example.com:8443
  SSM_SERVER_ID: vault.example.com
  SSM_PIN: <server pin from the app>
  SSM_ENVIRONMENT_ID: <from the app>
  SSM_CI_KEY: ${{ secrets.SSM_CI_KEY }}
steps:
  - uses: actions/checkout@v4
  - run: pip install "git+https://github.com/maheshmrs/SoloSecretsManager-SDK#subdirectory=python"
  - run: python deploy.py   # reads secrets with Client.from_env()

Values never touch the logs unless your own code prints them.

SDKs: setup

SDKs for Go, Python, Node, Java/Kotlin, .NET and Rust read secrets inside your own code. Source code, tests and READMEs: github.com/maheshmrs/SoloSecretsManager-SDK (open source, Apache-2.0). Each one reads its settings from environment variables, so the code is the same everywhere:

env:
  SSM_URL: https://vault.example.com:8443
  SSM_SERVER_ID: vault.example.com
  SSM_PIN: <server pin from the app>
  SSM_ENVIRONMENT_ID: <from the app>
  SSM_CI_KEY: ${{ secrets.SSM_CI_KEY }}   # GitHub and GitLab

Secrets are kept in memory for 5 minutes, then fetched again.

SDKs: examples

Each example reads the secret DATABASE_PASSWORD.

Python

from solosecretsmanager import Client

password = Client.from_env().get("DATABASE_PASSWORD")

Node

import { Client } from "@solosecretsmanager/sdk";

const password = await Client.fromEnv().get("DATABASE_PASSWORD");

Go

c, err := ssm.FromEnv()
if err != nil { return err }
password, err := c.Get(ctx, "DATABASE_PASSWORD")

Java / Kotlin

import com.aidigiapps.solosecretsmanager.sdk.Client;

String password = Client.fromEnv().get("DATABASE_PASSWORD");

.NET

using SoloSecretsManager.Sdk;

var password = await Client.FromEnv().GetAsync("DATABASE_PASSWORD");

Rust

let mut c = solosecretsmanager::Client::from_env()?;
let password = c.get("DATABASE_PASSWORD")?;

GitLab, AWS, Azure and GCP

The SDKs pick how to sign in from the variables they find. The app's grant screen shows exactly what to set.

Cloud workloads need no CI key: only that role or identity can use its key, so a copied setting alone is useless.

Good habits

• Give each pipeline its own grant for one environment. Revoke it when you stop using it.
• Prefer ssm run over ssm env; ssm env prints secrets as plain text.
• Never print secrets in logs or commit them, even in examples.