Ruust
PricingBountiesDocs
Deploy an Egg ✦
DocsEnvironment variables

Environment variables

Set environment variables on an Egg: encrypted at rest, available at build and run time, and delivered out of band so they never land in a log.

Environment variables are how you hand an Egg its configuration and secrets: database URLs, API keys, feature flags. You set them on the Egg itself, so the same value follows the Egg through every deploy without living in your repo. Ruust encrypts them at rest and delivers them to the container out of band, so a secret never appears in build output or in your logs.

Add and edit them

  1. Open your Egg in the dashboard and go to the Environment section on the Egg page.
  2. Add each variable as a KEY and a value, one at a time in the add form.
  3. Save. Ruust encrypts the values and stores them against the Egg.
  4. A run-time change rolls the container automatically: Ruust bumps an env hash in desired state, so the new values take effect on the next reconcile, with no manual redeploy needed.

Variables are scoped to a single Egg. If two Eggs in the same Coop need the same secret, set it on each. There is no shared global store, which keeps a compromised Egg from leaking another Egg's keys.

Build time and run time

Your variables are present both when Ruust builds the Egg (with Nixpacks or your Dockerfile) and when the long-running container serves traffic. That means a secret needed by a build step, say a private package token or a bundler key, is available before the first deploy. Set those before you lay the Egg, otherwise the first build runs without them.

Client-exposed variables

Anything shipped to the browser must carry your framework's public prefix: NEXT_PUBLIC_ for Next.js, VITE_ for Vite, NUXT_PUBLIC_ for Nuxt. These are baked into the client bundle at build time, so changing one only takes effect on a fresh build (push a commit and deploy to rebuild the image). Never give a real secret a public prefix, because it ends up in code the browser can read.

bash
# Server-only, read at run time
DATABASE_URL=postgres://user:[email protected]:5432/app

# Exposed to the browser, baked in at build time
NEXT_PUBLIC_API_BASE=https://api.example.com
Public-prefixed vars reach the client; everything else stays server-side.

Referencing another Egg

To let one Egg talk to another over private networking, turn on private networking and peer the two Eggs from the Coop board. Once connected, each Egg reaches the other by its private hostname, so you point a variable at that hostname rather than a public URL. When you link an Egg, the picker lists its Coop siblings, but a linked alias only resolves once both Eggs have private networking on and are peered, so it is not reachable until then. Only peered Eggs can connect, everything else is denied by default.

bash
# 'db' is a peered Egg in the same Coop
DATABASE_URL=postgres://app:secret@db:5432/app
REDIS_URL=redis://cache:6379
Use the peered Egg's private hostname, not its public address.

Sending email

To send email from an Egg, use an authenticated relay and point your app at it with environment variables (the relay host, port, username and API key or password). Direct SMTP on port 25 is blocked on every Egg: it is the route spam takes straight to recipients' mail servers, and leaving it open would put our host IPs and the shared ruust.run reputation on blocklists, which would hurt every customer. Submission ports 587 and 465 stay open, so any proper relay works. We recommend MailJunky for deliverability that does not depend on the Egg's own IP.

Deploy on Ruust ->