Vallic Cloud examples

Working configuration for running an application on Vallic Cloud, one folder per stack. Copy the files from the folder that matches your project into the root of your repository and adjust what is yours — the service versions, the build steps, the commands.

Everything here follows the handbook, which is the reference: docs.vallic.com.

Stacks

Folder	Application	Handbook
drupal/	Drupal 10 or 11, drupal/recommended-project layout	Drupal
drupal-dedicated/	A large Drupal site on Dedicated: several web servers, workers, Solr, Redis, RabbitMQ, Vinyl Cache (Varnish), an extra, a Node theme build, config overridden per environment	Shapes · Drupal
wordpress/	WordPress, classic layout	WordPress
laravel/	Laravel 12 or 13	Laravel
php/	Any other PHP application, and Symfony	PHP-FPM · Symfony
nodejs/	Any Node.js application that serves its own HTTP	Node, Go and Rust
nextjs/	Next.js	Node.js
express/	Express	Node, Go and Rust
bun/	A Node.js project run by Bun in Node's place	Bun
go/	A Go binary that serves its own HTTP	Node, Go and Rust
rust/	A Rust binary that serves its own HTTP — Axum, on PostgreSQL	Rust · Node, Go and Rust
python/	Flask, FastAPI or any other Python application, under Gunicorn or Uvicorn	Python
django/	Django, with Celery	Django
rails/	Rails 8, with Solid Cache, Queue and Cable	Rails
static/	A static site or single-page application, served by nginx with nothing behind it	Static site

Beside a stack

Folder	What it shows	Handbook
varnish/	Rules of your own for Vinyl Cache (Varnish) — .vallic/varnish/*.vcl	Vinyl Cache (Varnish)
extras/	A machine of your own beside the site, running containers from a compose file	Extra machines

Every stack folder but static/ also has a .vallic/commands/sanitization.yml: what to scrub from a database copied into staging or development. A static site has no database. See Sanitising what arrives.

What lives where

vallic.yaml                         the manifest — required, at the root
.vallic/commands/sanitization.yml   scrubbing after a copy or restore, never on production
.vallic/varnish/*.vcl               additions to the cache policy, when the stack runs Varnish
.vallic/extra/<slot>.yml            what runs on an extra machine
.vallic/extra/<slot>/               the files those containers mount

Application facts go in the repository; infrastructure is chosen in the console. Machine sizes, regions and the database are bought, not committed. A services entry starts a cache or a search engine on the next deploy. The database it names is taken only by the first deploy, while the environment's is still empty; after that it is fixed, and a file naming another is refused. See vallic.yaml.

The language is the project's. type and the version key under runtime — php, node (or bun), go, rust, python, ruby, or nginx for a static site — have to agree with the application chosen when the project was bought. A Node.js, Go, Rust, Python or Ruby application is its own web server, with no nginx in front unless its vallic.yaml names one.

Mail leaves through a provider. Every stack but a static site runs an OpenSMTPD relay your application sends to on port 25, inside the stack. Every example names a provider for it under services — SendGrid, over STARTTLS on 587 — because port 25 to the internet is refused on every machine, and without a relay host mail never leaves. Put your provider there, and its password in the console as RELAY_PASSWORD. See OpenSMTPD.

A service's settings are not variables. The relay's provider, an upload limit, whether Valkey keeps its data on disk: each goes under its service in vallic.yaml. An environment that needs a value of its own — a staging mail account — sets it on that environment's Variables page, under Service settings. A variable of the same name reaches your application only, and the service never sees it. See Service settings.

Credentials never go in the repository. Every example reads them from the environment the platform writes — the full list is in Variables. A variable your application cannot start without goes under env.required in vallic.yaml, and its value in the console, marked secret. Add variable → Bulk takes a pasted .env.

Versions

The versions written here are the platform's defaults — what an environment runs when nothing names one: PHP 8.5, Node.js 26, Python 3.14, Ruby 4.0, Go 1.27, Rust 1.99, Bun 1.4, nginx 1.31, MariaDB 11.8, PostgreSQL 18, Valkey 9.0, Redis 8.6, Solr 10, RabbitMQ 4.3, Vinyl Cache 8.0 and OpenSMTPD 7.8. Name the version you depend on, not a build of it: php: '8.5', mariadb: '11.8'. The platform matches it to the current build, so a security rebuild reaches you without a commit. What is on offer is listed in Software stacks.

Changing the version of a service that keeps data — the database, Solr's index, RabbitMQ's queues — is not always something it survives. Read Service upgrade before moving an environment that is already running.

The Python, Django and Rust examples commit their lock files — uv.lock and Cargo.lock — because their builds install exactly what the lock says. Run uv lock or cargo update after changing dependencies.