Open source · Apache-2.0 · self-hosted · written in Rust

Access you can prove.

Limen replaces SSH keys, shared database passwords and CI secrets with a sign-in through your identity provider. Engineers and CI jobs get short-lived, audited access to SSH, databases, Kubernetes and internal apps, and every session leaves a trail you can verify yourself.

Try it on your laptopRead the docs
  • 1 hour certificates, no static keys
  • 0 inbound ports
  • 1 required store: PostgreSQL
Credentials that expire. By design.
See it work

A session, and the proof it leaves.

Every command below writes an audit event, and each event's hash includes the one before it. Edit anything in the past and the chain stops verifying. Press the tamper button and see.

A replayed terminal session. The audit events it produces appear in the list beside it.

Illustrative output. The commands are real; see the CLI guide.
Audit trail
each hash covers the previous one
chain intact

    A simplified picture of the idea. The real trail is batched, signed, and chained per writer in S3, and limen-audit-verify walks it.

    How it works

    What happens when you connect.

    1. 01

      Sign in

      Through the identity provider you already run. Your login is tied to a key that never leaves your machine.

      limen login
    2. 02

      Policy decides

      Your IdP groups become roles, and roles reach resources by label. Anything no rule allows is denied, and you can ask why.

      limen explain orders-prod
    3. 03

      Connect

      You get a certificate that lasts an hour, or less if you choose. A worker inside your network dials out to Limen, so your targets open no inbound port.

      limen db connect orders-staging
    4. 04

      Prove

      Every session is recorded or audited into a signed, hash-chained trail. Anyone who can read the bucket can check it.

      limen-audit-verify --bucket …
    See the architecture diagrams →
    Who it is for

    For the people who get paged, and the people who get audited.

    Developers

    Get in, get on with it.

    Sign in once. limen ls shows what you can reach. Keep using ssh, psql and kubectl, with no passwords or keys to look after. When you need more, ask for it, with a reason.

    The CLI →
    Platform and SRE

    Run it like the rest of your stack.

    Policy in Git, tested in CI. Workers dial out, so you open no inbound holes. Run several copies of each part behind a load balancer. Prometheus metrics, OpenTelemetry traces and ready-made alerts.

    Running at scale →
    Security and compliance

    Evidence, not promises.

    A signed, hash-chained trail. Recordings that are checked before playback. Access reviews with signed evidence packs. A threat model and pen-test plan you can read before you trust it.

    The threat model →
    Why Limen

    A door that keeps a record you can check.

    Knowing who connected is the start. Limen is built so that every grant, every decision and every session can be checked by someone who doesn't have to trust Limen.

    ▣ Provable

    The audit trail is signed and hash-chained. Each control plane's S3 batches name the previous batch's hash, so a missing, reordered or altered batch is found by one command.

    # walks every writer's chain
$ limen-audit-verify --bucket audit --ca-file internal-ca.pem
✔ chain intact
    Verifying the chain →

    ? Explainable and testable

    Policy is YAML in Git, with tests that run in CI. Ask who can reach what, diff effective access, and get the reason for a denial.

    kind: policy_test
- name: devs cannot ssh to prod as root
  resource: orders-prod
  expect: deny
    Policy tooling →

    ⏱ Short-lived and justified

    Access you ask for, with a reason. The approver sees what you did on that resource in the past 30 days. When the grant expires, so do the sessions it allowed.

    $ limen request orders-prod --for 30m \
    --reason "INC-123: orders is locked" --wait
    Requests and break-glass →

    ⚙ CI jobs are principals too

    A GitHub Actions or GitLab CI job signs in with its own token and gets a scoped, short-lived bot login. The run is named in every audit event. No secret lives in the repository.

    $ limen login --bot github_actions
$ limen ssh web-staging-1 -- ./deploy.sh
    Bots →

    ◇ Open and plain to run

    Everything on this page is in the Apache-2.0 build. Static binaries, PostgreSQL as the only required store, workers that dial out. No paid tier for approvals, auditing or discovery.

    • Apache-2.0
    • Rust, static binaries
    • PostgreSQL only
    • Outbound-only workers
    • Docker Compose, Terraform for audit
    • Prometheus and OpenTelemetry
    What it connects to

    One policy and one audit trail for all of it.

    Each tile says where it stands. built means it works and is tested against a local copy of the software. unverified marks a cloud-specific path that is written but has not yet run against the real service.

    builtSSHPer-session certificates, recorded and replayablebuiltPostgreSQLRDS, Aurora, Redshift. Every statement auditedUnverified: IAM and Redshift on AWSbuiltMySQLRDS and Aurora. Every statement auditedUnverified: IAM on AWSbuiltRedis and ValkeyValues redacted in auditUnverified: ElastiCache IAMbuiltKubernetesImpersonation, recorded execUnverified: EKS. Works on kindbuiltMongoDBAny server, Atlas, DocumentDBUnverified: Atlas and DocumentDBbuiltOpenSearch and ElasticsearchPolicy by index patternUnverified: Amazon OpenSearch and Elastic CloudbuiltRabbitMQNo message bodies in auditUnverified: Amazon MQbuiltKafkaRecord values never auditedUnverified: MSK and IAMbuiltInternal web appsSSO in front of any web UI, every request auditedbuiltRaw TCPAnything else, through a local portbuiltCI botsGitHub Actions, GitLab CI, any OIDC. No long-lived secretsUnverified: Real CI tokens. Tested with a stand-in

    We tell you what isn't proven.

    Limen is tested thoroughly against local stand-ins. It has not yet been verified against real AWS, Okta or Datadog. Those checks are on the roadmap, one issue per service, and every page that describes a capability says whether it has met the real thing.

    The status pageVerification roadmap
    • Local stand-ins: Dex, databases and brokers in containers, local S3 and KMStested
    • Real AWS: RDS, EKS, MSK, KMS and morenot yet
    • Real Oktanot yet
    • Real Datadognot yet
    Try it

    From clone to a recorded session, on your laptop.

    terminal
    $ git clone https://github.com/limen-dev/limen && cd limen
$ deploy/compose/setup.sh
$ scripts/install-cli.sh
$ limen --proxy localhost:3443 login --ca-file deploy/compose/.state/internal-ca.pem
$ limen ssh web-staging-1

    Needs Docker and the tools in mise.toml. The first build takes several minutes. This is a local stack with test users and passwords, not for production.

    Read the quickstartStar on GitHub