Environment and envoryx.yml

Configuration reaches your application through environment variables. Some of them Envoryx sets on its own, the rest are yours. And if you want the whole project setup to live next to your code, there’s envoryx.yml.

What Envoryx sets for you

Every application container gets the connection details of the project’s services as environment variables. For the database that’s DB_HOST, DB_DATABASE, DB_USERNAME, DB_PASSWORD and DATABASE_URL; for the other services it’s REDIS_URL, MAIL_*, MAILER_DSN and so on (the databases and services pages list them all). Most frameworks pick these up directly - Laravel, Symfony and Rails don’t need a single database line in their .env.

There’s also ENVORYX_URL, the address the project answers at. Put APP_URL=${ENVORYX_URL} in your .env and it follows along, even after a rename. The Laravel template does that for you, and the Symfony template writes DEFAULT_URI=${ENVORYX_URL} to .env.local, so links in mails and anything else built outside a request point at the project instead of http://localhost.

A project with a Node.js dev server also gets ENVORYX_DEV_URL, the dev server’s own address (https://shop-dev.test for shop). It’s meant for a backend page that loads its scripts from the dev server. Laravel with Vite is the classic case: the page comes from PHP, the assets and the hot reload socket from Vite, and the browser has to reach Vite through the proxy, not at http://0.0.0.0:5173. The Laravel template’s vite.config.js takes its origin and its hot reload settings from the variable, so this works out of the box there; the PHP page shows what to add to a Laravel app you brought along.

Your own variables

The Environment section (or Advanced settings → Environment in the wizard) holds the variables you add yourself. They reach every container of the project and win over whatever Envoryx sets for the services. Mark a variable as a secret and its value gets masked in the interface; viewers and read tokens don’t get it at all.

Most of the time you’ll already have a .env lying around, and Import .env takes it over. Paste it or pick the file. It understands the format Laravel, Symfony and docker compose write (export, comments, quotes, ${OTHER} references) and shows you what it found before anything is saved. A reference is only resolved when OTHER is defined earlier in the same file. One that points elsewhere, like the Laravel template’s APP_URL=${ENVORYX_URL}, is marked refers to and left unticked: only your application’s .env loader resolves it, and as a project variable it would reach the containers as the literal text. Leave such lines in .env.

It’s a bit picky on purpose. New variables and changed values are preselected, unchanged ones aren’t. Variables Envoryx already sets for one of the project’s services (DB_HOST, DB_PASSWORD, REDIS_HOST, MAIL_* …) stay unticked unless you pick them yourself - otherwise an old DB_HOST=127.0.0.1 would quietly point your application away from the project database. Names Envoryx doesn’t accept (lower case, MARIADB_*, POSTGRES_*, ENVORYX_* …) and values with line breaks are shown but can’t be imported. Secrets are recognised by their name (*_PASSWORD, *_SECRET, *_TOKEN, APP_KEY, *_KEY …) or by a password inside a URL.

Nothing is stored until you hit save. The other direction works too: Export .env downloads your variables as a .env file, secrets in plain text. The service variables aren’t part of it.

The project manifest (envoryx.yml)

envoryx.yml describes a project inside its own repository: runtimes, services, domains, environment, workers and cron jobs. Commit it with the code, and anyone with a fresh clone is one command away from the same environment:

git clone git@github.com:acme/shop.git && cd shop
envoryx up                        # creates "shop" on the server, or brings it in line
envoryx up --dry-run              # only show what would change
envoryx project manifest shop -o envoryx.yml   # write the file for an existing project

Here’s what a full one can look like:

version: 1
name: shop
docroot: public
web: {server: nginx}             # caddy (default), apache, nginx
php:
  version: "8.4"
  extensions: [bcmath, intl, pdo_mysql, redis, zip]
  memoryLimit: 512M              # also uploadMaxFilesize, postMaxSize, maxExecutionTime,
  xdebug: true                   # displayErrors, errorReporting, xdebugMode, xdebugIdeKey
database: {type: mariadb, version: "11.4", exposePort: true}
databases:                       # additional databases, reached by their name
  analytics: {type: postgres}    # host analytics, ANALYTICS_DB_* variables
redis: true                      # or {version: "8", exposePort: true}
mailpit: true                    # also memcached, rabbitmq, meilisearch, typesense,
opensearch: {dashboards: true}   # opensearch, storage: {publicRead: true}
domains: [api.shop.example.com]
env:
  APP_ENV: local
secrets: [STRIPE_SECRET]         # names only - values never go into the repository
workers:
  - {name: queue, preset: "laravel:queue", arg: default}
cron:
  - {name: prune, schedule: "0 3 * * *", command: php artisan model:prune, timeout: 5m}
limits:
  app: {cpus: 2, memory: 2G}
  services: {memory: 1G}
  pids: 4096
healthcheck:
  path: /health
addons:                          # installed addon files, see the addons page
  phpmyadmin: true

node:, python:, go:, ruby:, java: and dotnet: take the same fields as the wizard - for Ruby that’s server, mode, preset, port, debug and debugPort, for example, Java adds jar, and .NET takes project and dll instead of the debug fields. Whatever you leave out means Envoryx’s default, which is what makes the file the complete desired state. Unknown keys are errors, so a typo never silently drops a service. An exported file pins every version, and that’s why envoryx up can reproduce a project exactly. Addons go under addons: by name, and the server you run envoryx up against needs the addon file installed. One default worth knowing: storage: true creates a private bucket, and only storage: {publicRead: true} makes it readable for everyone.

A few things deliberately stay out of the file: host ports (the server hands those out), generated credentials, the repository itself, backup schedules and the Xdebug client host. Secret values never go into the repository either - envoryx up asks for each one the project doesn’t have yet in the terminal, or you pass one with --secret KEY=VALUE.

envoryx up is also careful about removing things. A service, variable, domain, worker or cron job that the file no longer mentions is listed as kept, and only disappears with --prune - a database or a service with a volume together with its data. A database version lower than the project’s current one is never applied.

To find the project, envoryx up uses name: from the file, --name or the folder name. If the server doesn’t have a project of that name yet, it clones the repository itself (the origin remote and the checked-out branch) and creates the project as described. If the project exists, it applies the differences in one restart.

In the web interface, the Git section shows the project as envoryx.yml - copy it, download it or save it into the project folder - and compares the file in the project folder with the project. When a git pull brought in a changed manifest, Apply to project takes it over. And the wizard applies the manifest of any repository it clones.