SvenskaBook a demo

One platform for every workload

Apps, machines and clusters for every organisation on the installation, each kept to the sizes and permissions it was given.

  • Containers

    Rootless on youki, with revisions, rollouts and automatic rollback.

  • Sandboxed apps

    The same image in a microVM with its own kernel, where operators require it.

  • Virtual machines

    On Cloud Hypervisor, Linux and Windows Server alike.

  • Build jobs

    One-shot CI and build jobs, in Firecracker microVMs by default.

  • Kubernetes

    Managed RKE2 or k3s, and a Kubernetes-compatible API for kubectl.

  • Registry

    An OCI image registry with organisation namespaces and quotas.

  • Git servers

    Forgejo as a managed app, signed in through Velrix, with CI runs as jobs.

  • Networks

    Geneve overlays, security groups, floating IPs and load balancers.

  • Ingress

    Hostnames on ports 80 and 443 with certificates, spread over healthy copies.

  • Volumes

    Storage with enforced sizes, attached to apps and machines.

  • Browser desktop

    Windowed apps, a desktop and files, for people and operators alike.

  • Cloud shells

    Browser shells signed in to Velrix, in a container or microVM.

  • Availability

    Policies per app and host pool, drain, and live migration of VMs.

  • Backups

    Platform state, volumes, and VM disks frozen for a consistent copy.

  • Logs

    History, search and live tail per deployment; network and DNS logs.

  • Policies

    Every module’s policies in one app, while each module keeps and enforces its own.

  • Hardware health

    Sensors, disk health and management controllers, with thresholds and warnings.

  • Running the realm

    Add, move or remove module copies from the Manager, run several edges, and use a console on each server.

Nothing in the middle

Most cloud platforms have a control plane that everything depends on. Velrix has none. Each platform service is a module: one static Rust binary in its own rootless container, which finds the others, proves who it is and tests them continuously.

No central broker
No central process routes, schedules or brokers the modules. Routes follow the live sessions between them.
Mutual TLS over QUIC
Every module session has post‑quantum key exchange and pins the peer’s authority; frames are schema‑checked.
Tested by its peers
Modules run each other’s contract tests on connect and on an interval. A provider that answers wrongly loses its routes.
Access decided where it is used
Signed session tokens carry a person’s roles, so most access checks are decided locally, with no round trip.

Your brand, your platform

Velrix takes on the look of whoever runs it. Operators change it inside the platform, with no rebuild, and the sign-in, the desk and every window follow.

  • Name, colour and wallpaper

    The instance’s own name, a brand colour or a two-colour gradient, and a wallpaper of its own.

  • A colour per organisation

    On an organisation’s desktop its own colour takes over, so each customer of a provider sees its own brand.

  • The design contract

    Button style, density, control size and corner radius, with Lucide icons. Every module’s windows follow it.

  • Your own words

    Override any text per language in the Languages app, and add languages of your own.

  • Your own address

    The web client is served by your own installation, at the host name you give it, never by us.

  • Your terms and catalogue

    Your own sign-up terms and privacy policy, versioned, and your own sizes, prices and blueprints.

Automate with the tools you have

The provider, the collection and the MCP server are generated from the same contracts the modules speak, so they stay in step with the platform.

Terraform and OpenTofu
Apps, volumes, machines, projects, keys and address pools as resources.
Ansible
Apps, volumes, machines, keys, address pools and jobs, with machines as inventory.
Runs inside Velrix
Plan, approve and apply OpenTofu and Ansible runs, with state kept in Velrix.
Kubernetes API
kubectl and Helm against a Kubernetes-compatible API that maps onto your Velrix apps.
MCP server
AI assistants act with the caller’s own scoped API key, nothing more.
resource "velrix_app" "web" {
  name       = "web"
  image      = "docker.io/library/nginx:alpine"
  memory_mib = 128
}

resource "velrix_volume" "data" {
  name            = "web-data"
  size_mib        = 512
  attached_app_id = velrix_app.web.id
  attached_path   = "/usr/share/nginx/html"
}

See Velrixon your own terms

We walk through the platform and the architecture, and how Velrix would run in your organisation.

Book a demoSee pricing