Environment variables

Set variables once, restart, and they are in every ssh session and available to your services. No config files to copy around.

Two scopes

Variables live at one of two levels:

Scope	How to set	Applies to
account-wide	`env set NAME VALUE`	every machine you own
per-machine	`env set NAME VALUE --machine=<name>`	that machine only

Same name in both scopes: the machine value wins. Put shared defaults at the account level; override per machine where needed. The flag is --machine=<name> (short form -m=<name>) and can appear anywhere in the command.

Setting a variable

ssh

$ ssh dashboard@ironwire.sh env set DATABASE_URL postgres://db.example/app
set DATABASE_URL — restart the machine to apply

Or scoped to a single machine:

$ ssh dashboard@ironwire.sh env set LOG_LEVEL debug --machine=api
set LOG_LEVEL — restart the machine to apply

dashboard

Press e for the account-wide env vars screen and add the variable there. For a per-machine variable, select the machine, press Space for the actions popup, and choose env vars.

env set replaces any existing value for that name; setting it again overwrites. Everything after the name is joined with spaces to form the value.

Names must start with a letter or underscore and contain only letters, digits, and underscores. Invalid names are rejected with invalid variable name "<n>" (use letters, digits, and underscore; must not start with a digit). Names starting with IRONWIRE_ are refused: names starting with IRONWIRE_ are reserved by the control plane.

When changes take effect

Values reach a machine at boot: they are stored encrypted at rest on the platform and injected into the machine when it starts. After a set or rm, restart the machine to apply:

$ ssh dashboard@ironwire.sh restart api
restarted api

At boot the machine installs the variables in three places, all regenerated from the same set:

Where	Who sees it
every ssh session (login shells via `/etc/profile.d/ironwire-env.sh`, and non-login ones, `ssh <handle>+<machine>@ironwire.sh <cmd>`, via PAM)	anything you run over ssh
`/run/ironwire/env` (root-only, tmpfs, never on disk)	systemd services: add `EnvironmentFile=/run/ironwire/env` to the unit's `[Service]` section

note Changes never apply to an already-running machine until it restarts. A value containing a newline or an awkward mix of quotes is still set for login shells and services, but cannot be expressed in the PAM file and is skipped there.

Listing variables

ssh

$ ssh dashboard@ironwire.sh env
DATABASE_URL=postgres://db.example/app

dashboard

Press e to see the account-wide variables; a machine's own variables are under Space → env vars.

env with no subcommand lists the account-wide scope. Add --machine=<name> to list a machine's own variables. An empty scope prints no variables.

Removing a variable

ssh

$ ssh dashboard@ironwire.sh env rm LOG_LEVEL --machine=api
removed LOG_LEVEL — restart the machine to apply

dashboard

Open the env vars screen (e for account-wide, Space → env vars for a machine) and remove the variable there.

Removing a name that does not exist in that scope fails with no variable named "<n>".

Injected IRONWIRE_* variables

Every machine also receives platform-injected variables at boot. They are applied after yours, so they cannot be shadowed; that is why the IRONWIRE_ prefix is reserved. Two are useful in your own programs:

Variable	Meaning
`IRONWIRE_MACHINE_NAME`	this machine's name
`IRONWIRE_MACHINE_IP`	this machine's IP address

A few more IRONWIRE_* variables exist as plumbing for the in-machine tooling (where the platform is, how to authenticate to it). They are consumed automatically and your programs never need to.