Concepts

Documentation Index

Fetch the complete documentation index at: https://docs.envless.cloud/llms.txt

Use this file to discover all available pages before exploring further.

Envless is a sync layer for environment variables. You manage variables in the dashboard; your machines pull them down, decrypted locally. There are three ways to do that pull, and which one you pick depends on where the code runs.

​

Three ways to sync

Import in your app

import { env } from '@goenvless/envless' — typed, decrypted at boot, no files on disk.

Sync to .env files

envless sync — writes .env.<slug> for tools that expect a file (Docker, Python, Rails, shell).

Wrap a process

envless run -- <cmd> — inject variables into a single child process, nothing persisted.

​

When to pick which

They’re not mutually exclusive. A typical setup uses import in app code, sync for the docker-compose dev stack, and run in CI.

​

What makes them work

All three modes share the same three pieces underneath:

​

The .envless file

A small JSON file you commit to your repo. It tells Envless what to fetch — workspace, project, and one or more environments — and contains no secrets.

{
    "workspace": "acme",
    "project": "my-app",
    "environments": ["development", "staging"]
}

Created by envless link. Safe to commit and share.

​

The workspace key

Envless is end-to-end encrypted. The server stores ciphertext only; decryption happens on your machine with a key derived from a workspace passphrase.

​

Server vs client split

Every variable has a visibility flag — server (default) or client. The runtime ships two entry points:

import { env } from '@goenvless/envless/server';  // all variables
import { env } from '@goenvless/envless/client';  // client-flagged only

Server secrets can’t end up in a client bundle — enforced by types, runtime, bundler, and lint. See Server vs Client.

​

How a sync actually flows

┌────────────────────────────────────────┐
│  Dashboard (you manage variables here) │
└──────────────────┬─────────────────────┘
                   │  encrypted blobs
                   ▼
┌────────────────────────────────────────┐
│        Envless API (ciphertext only)   │
└──────────────────┬─────────────────────┘
                   │  fetch (auth: token or key)
                   ▼
┌────────────────────────────────────────┐
│  Your machine                          │
│    ~/.envless/config.json  ← key       │
│    .envless                ← binding   │
│                                        │
│    decrypt locally, then:              │
│      • import { env }     (runtime)    │
│      • write .env.<slug>  (sync)       │
│      • inject into child  (run)        │
└────────────────────────────────────────┘

One pipeline above the bottom box; three ways out of it.

​

Beyond syncing: API and SDK

Envless also ships a REST API and a programmatic SDK — but these aren’t for getting variables into your app. They’re for advanced workflows like building tools on top of Envless: writing custom dashboards, scripting workspace/project/variable management, integrating with internal platforms, or automating bulk operations across many projects.

~99% of apps never need these. If you’re just trying to use your variables — import them, sync them to a file, or wrap a process — stick with the three modes above. Reach for the API or SDK only when you’re building on top of Envless rather than using it.

API Reference

Raw HTTP endpoints for everything the dashboard does — projects, environments, variables, members.

SDK

Typed wrapper around the API. Same surface, with auth, retries, and pagination handled for you.

​

Glossary

Quick reference for the resource model you’ll see in the dashboard and the .envless file: