From office to apps
Our whole office runs on one small server behind our own Viaalink Relay: project management, sign-in, passwords, mail, analytics, a local AI model. How it fits together, why the Relay is the web server, and why we are turning it into via apps.
TL;DR: Our office runs on one mini-PC with our own Viaalink Relay in front of it. Every service gets an HTTPS address under our domain, without a single port opened on the router of the machine that runs it. Because the Relay is the web server, we can move a service to another machine in minutes, with no DNS change and no new certificate. We are now bringing these apps together as via apps, in a public repository.
One small box, a whole office
Everything we use day to day runs on a single mini-PC in our office: a Ryzen AI 9 HX 470 with its Radeon 890M graphics and 58 GB of memory, running Proxmox, on around the clock. On it:
| What | For |
|---|---|
| Our internal office application suite, with its own MCP server and OAuth 2.1 sign-in | Plans, tickets and sessions, readable by AI assistants |
| Authentik | One sign-in for everything |
| Vaultwarden | Passwords, only through that sign-in |
| Gitea | Packages and container images |
| Redmine and Zammad | Issues and the helpdesk |
| n8n | Automations between all of the above |
| Umami | Website statistics, without cookies |
| Postal and a send-only mail server | Mail from every app, through one gateway |
| Firecrawl | A self-hosted web crawler |
| llama.cpp with Open WebUI | A local AI model (Gemma) on the built-in graphics chip |
| The Digitale Kraamzorg content studio (CMS, MCP server and website) and the nuttigwerk.nl job-site pipeline | Work for customers, built and served from the same box |
Containers can share the graphics chip, so the AI model and the work that needs it run in containers rather than full virtual machines.
How a request finds its app
Our Relay runs on a NAS in the same office. It holds our domain, the wildcard certificate and every name. The machine that runs the apps connects out to the Relay; nothing connects in.
browser
│ https://projects.office.example.com
▼
DNS: *.office.example.com → our Relay
▼
Relay: HTTPS, certificate, picks the machine by name
▼
the connection that machine opened to the Relay
▼
Caddy on that machine → the app on 127.0.0.1Each project has a via.yaml file. A service marked public: true gets a name on the Relay; anything not marked has no route at all, so it cannot be reached from outside even by accident. When the machine starts, it publishes its services again by itself. For a quick one-off, via expose <port> publishes a single port.
The Relay is the web server
This is the part people tend to miss. In most setups, the machine that runs an app is also where its certificate lives, where its web server is configured, and where DNS points. Move the app and all three move with it.
With a Relay, all three stay on the Relay. The machine behind it only runs the app and keeps one connection open. That has two consequences we use every week.
Moving a service takes minutes
On 31 October we moved the Digitale Kraamzorg content studio from a development workstation to a container on the office server. The steps: stop publishing on the old machine, take a last database dump, restore it on the new one, compare the row counts, publish the same names from the new machine. A few minutes of “not found”, then the same pages as before. No DNS record changed, no certificate was issued, and the AI assistants connected to its MCP server kept working, because the address they talk to never changed.
One lesson: switch the old publisher off for good. A forgotten development checkout on the old machine later published the same names again and took the route back.
One name, several machines
A Relay can let several machines hold the same name and spread requests across them in turn, round-robin. A machine that keeps failing gets fewer requests until it recovers. When a service gets busy, or you want a second copy running somewhere else, you start it on another machine under the same name. Nothing changes for the people using it. Turn on HTTP load balancer under Network in the Relay dashboard; it is off by default. See Relay configuration.
Via apps
What started as our own office is becoming a product. Our internal office application suite holds 66 packaged apps, and we are converting them into via apps: each one a package with its own via.yaml, ready to start on your own machine and publish through your own Relay. They move to a new public repository, viaalink/apps, with an app catalogue on viaalink.com and installation from the Viaalink CLI. The suite that runs our own office stays internal and installs from that same catalogue. We will link the repository here when it opens.
A Relay on your own NAS
Our Relay runs on a NAS, and yours can too. The Viaalink Relay package for ASUSTOR is in review for App Central, and the Synology package is in review for Package Center, so both will be a download in their app stores very soon. Until then: Run Relay on ASUSTOR, and on Synology with Docker.
Everything above already works today with a Relay and the Viaalink CLI.
Read the quick start