Configuration

The three that matter

Everything else has a sensible default. These do not.

LINKR_SECRET_KEY=<a long random string>        # required
LINKR_DATA_DIR=/var/lib/linkr                  # this is what you back up
LINKR_CORS_ORIGINS=https://linkr.example.org   # the real public address
LINKR_DEBUG=false

The two keys

Linkr holds two, and mixing them up is the costliest mistake on this page: one only signs logins, the other seals stored secrets. Neither is derived from the other.

The encryption key seals three things: the database passwords each user chooses to remember, the IDE connection secrets and the git access tokens. Each secret is sealed together with what it protects — the user, the database and its address —, so a secret copied into another row no longer opens. Account passwords are not encrypted but hashed: neither key concerns them.

Keeping the encryption key outside the folder

By default there is nothing to do: secret.key is created on first use, readable by the server alone, and a backup of the data directory takes it along with the rest. If your policy wants keys in a secrets vault rather than next to the data, supply it yourself:

# 32 random bytes, "url-safe" base64
LINKR_ENCRYPTION_KEY=$(python3 -c "import secrets, base64; print(base64.urlsafe_b64encode(secrets.token_bytes(32)).decode())")

For an instance already running, reuse the contents of secret.key rather than a fresh key: a fresh key would make the existing secrets unreadable.

Changing the encryption key

Put the new key in LINKR_ENCRYPTION_KEY and the old one in LINKR_ENCRYPTION_OLD_KEYS — several old keys are separated by commas. Each secret records which key sealed it: old ones stay readable, new ones are sealed with the new key.

The data directory

One variable names the place where everything is stored. The folder is created on first start.

An automatic sweep runs at startup and every six hours: abandoned uploads, files nothing references any more, folders of deleted projects.

The application database

By default, a SQLite file stored in the data directory. For sustained multi-user use, PostgreSQL is recommended:

LINKR_DATABASE_URL=postgresql+asyncpg://linkr:password@localhost:5432/linkr

Code execution

This is the most sensitive part, and the most adjustable.

LINKR_ENABLE_CODE_EXECUTION=false   # turns execution off across the instance

The limits

Package repositories

Useful on a closed network, or to enforce an institutional mirror:

LINKR_PIP_INDEX_URL=https://pypi.internal.example/simple
LINKR_R_REPOS=https://cran.internal.example

Other variables

What is set inside the application

Not everything goes through variables. The Settings page carries six tabs, each protected by a permission — the tab stays visible, but its contents are replaced by a notice if you lack yours.

Organizations, users and roles are covered in Authentication and permissions, the catalogs — managed from the Catalog page itself — in Community catalog.

Each workspace also has its own settings — members, badges, default environments — described in Workspace settings.

Logs and monitoring

In production, logs are emitted as structured JSON on standard output: collect them with your platform’s log collector. In debug mode they switch to a human-readable console rendering.

The access log

Every request that reads data, changes something or is refused leaves one line: who, when, from where, by which path — the interface, an API key, a code session, a background job —, on which database, with which SQL or code, and how many rows came back. Never the data itself. The SQL and code can still name a patient, so reading this log takes the audit-log:read permission.

A failed line also carries its reason: why a request was refused, or the database’s message when a connection fails (password hidden). Finally, every request gets a reference. When the application answers with a deliberately vague message, “Connection failed” or “Internal server error”, it adds that reference (“ref. 3f9a1c07be42”). It can be found in the tab’s Reference column and on every server-log line the same request produced, with the full detail, including an internal error’s stack trace.

It is written in two places at once:

• In the data directory, under audit/: one file per day, compacted into one file per month. Months older than LINKR_AUDIT_RETENTION_DAYS are deleted.
• On standard output, with the other logs: that is the copy your platform’s log collector keeps.

Going further

• Production install — where to put these variables.
• Backup and restore — what the data directory implies.
• Files on the server — bounding what the picker reaches.
• Authentication and permissions — the rights that open these screens.