Available

Deploy to your cloud

Where Loams 0.1.1 runs today on AWS, Google Cloud, Azure, Cloudflare and Vercel, for a development VM and for production, and what is still planned.

Don't rent a cloud. Loam it. Loams runs in an account you own: your laptop, your homelab, or a VM in your own cloud. Ostrium runs no data plane, and the engine is never on the public internet.

This section says what works today, in 0.1.1, on each cloud, and labels the rest. Everything here is the same release: the compose bundle attached to the v0.1.1 GitHub release, its images on ghcr.io/ostrium-labs, and your own Tailscale tailnet as the only way in.

What works today

One Linux VM running the compose stack. That is the only install path in 0.1.1, on every cloud. The VM runs the light default stack, and the engine can keep its data in that cloud's object store. The stack and the tailnet are covered in Self-hosting over Tailscale; the pages below add what is specific to each cloud.

AWSGoogle CloudAzureCloudflareVercel
Development VMEC2Compute EngineAzure VMNo VMs. Run the VM on another cloud or your own machineNo VMs. The data plane is a VM elsewhere; the app runs locally on your tailnet
Production todayOne EC2 VM, bucket on S3One Compute Engine VM, bucket on Cloud StorageOne Azure VM, bucket on Blob StorageR2 as the bucket of a VM elsewhereNothing on Vercel yet: apps on Vercel cannot reach the engine until edge reach ships
Bucket credentialsThe instance role, no keysThe VM's service account, no keyA storage account keyAn R2 API token's S3 keysVercel Blob is not S3-compatible; use R2
PlannedOpenTofu modules, ECS Fargate, EKS with the operatorOpenTofu modules, Cloud Run, GKE with the operatorOpenTofu modules, Container Apps, AKS with the operatorA Deploy to Cloudflare template: the engine in a Container, R2 as the source of truth; apps on WorkersApps and agents on Vercel Functions, reaching the engine through edge reach; a Vercel integration
PageAWSGoogle CloudAzureCloudflareVercel

Every "today" cell is Available in 0.1.1, as one node with the limits below; every "planned" cell is designed and not built. Vercel never hosts the data plane: it runs apps and agents, and the engine runs on one of the other clouds or your own machine.

The stack on one VM

docker compose up -d in the bundle's release/ directory starts the light default:

  • the engine (loams) on its embedded stores: the metastore on openraft and redb, Loams Live on redb, Durable on SQLite, Git and Graph, with the bucket a local folder unless you point LOAMS_BUCKET at an object store;
  • Loams House, linked to the engine;
  • Loams Postgres: its storage broker, pageserver, safekeeper and one compute, with their remote storage in local folders;
  • agentd, the agent daemon;
  • the tailscale sidecar, the stack's only door.

Loams House runs on chDB today. It is ClickHouse-compatible analytics on chDB, the embedded ClickHouse library, inside the loams-fabric image, and it is experimental. A Rust engine of our own for the House is designed (design 75) but not built.

It needs about 10 GB of free disk and 2 GB of free memory, and it idles near 1 GB, measured on 0.1.0's images. Profiles add more, set in .env as COMPOSE_PROFILES before the first start:

ProfileAddsCost
tikvPD, TiKV and TiDB: Loams SQL, and the engine's metastore and Live on TiKVAbout 3 GB more of images and 2 GB more of memory
rustfsRustFS, an S3 bucket on the same machine for Loams Postgres's storageA little more disk

A stack's data stays on the stores it started on: the engine refuses to switch stores on existing data. Choose the profiles on the first start.

VM sizes

The default fits a small VM. Leave room for the operating system on top of the stack's 2 GB.

Light defaultWith tikv
Memory4 GiB8 GiB
Disk30 GB50 GB
AWSt3.mediumt3.large
Google Cloude2-mediume2-standard-2
AzureStandard_B2sStandard_B2ms or Standard_D2s_v5

The cost calculator prices these sizes side by side on each cloud, with the bucket, requests and egress. Loams itself is free.

Use Ubuntu 24.04 LTS on x86-64. Two reasons:

  • The House's workers need Landlock with TCP rules, from Linux 6.7, and refuse to boot without it. Ubuntu 24.04 ships a 6.8 kernel. Distributions on 6.1, such as Debian 12 and Amazon Linux 2023's default kernel, are too old for the House (verify for your image).
  • The loams, loams-fabric, loams-agentd and loams-pg-control images are built for amd64 and arm64, but the patched TiDB image is amd64 only, and the pinned Loams Postgres images on arm64 are not yet confirmed. x86-64 avoids both.

Never public

No step in this section opens a port to the internet.

  • People reach the engine over your tailnet, at https://loams.<tailnet>.ts.net, through the stack's tailscale sidecar. The VM needs outbound internet only.
  • Shell access goes through the cloud's own console or identity-aware tunnel, or over the tailnet once the VM is on it. Create every VM with no inbound firewall rules.
  • Machines on the tailnet, such as CI runners, use an API key (LOAMS_AUTH_MODE=tailscale,apikey), because Tailscale gives no user identity for tagged devices.
  • Callers off the tailnet, such as a serverless function, have no supported path in 0.1.1. The gateway's edge listener, reached over a private link or Cloudflare Tunnel with every request authenticated first, is Planned (design 69).

The console

WhereStatus
Loams Desktop: add https://loams.<tailnet>.ts.net as a server. Download it from the download pageAvailable in 0.1.1
Served by the engine at https://loams.<tailnet>.ts.net/ui/, same-origin with the APIPlanned for 0.1.2. It is merged on dev and not in 0.1.1
The hosted console at console.loams.devRetired
The console on your own Cloudflare or Vercel projectPlanned

Identity

WhatStatus
One organization per install, created once by first-run setup with LOAMS_SETUP_TOKEN, with you as its ownerAvailable
Sign-in modes tailscale (default), oidc with an OIDC issuer you choose, apikey for the CLI, SDKs and CIAvailable
Authorization is coarse: a valid identity can do anything the engine can. No per-namespace roles yetKnown limit
Zitadel for identity and OpenFGA for authorization (design 76)Planned

Upgrades

0.1.1 changes the default stack; reinstall. A 0.1.1 stack starts from the 0.1.1 bundle with a fresh .env. A 0.1.0 stack keeps its data only if you add COMPOSE_PROFILES=tikv,rustfs to its .env before upgrading, because 0.1.0 ran on TiKV and RustFS.

From then on, loams upgrade upgrades a stack with the tikv profile in place, with a snapshot first. It refuses a stack on the default embedded stores for now; upgrade one of those by hand: back up the volumes, docker compose stop, set LOAMS_VERSION in .env, then docker compose up -d. See upgrades.

What is planned

These are designed and approved, not built. None of them ships in 0.1.1.

PieceDesignStatus
Per-cloud cloud-init files and guides with the bucket, key and secrets in the cloud's own services70, BY0Planned
The Deploy to Cloudflare template: the engine in a Cloudflare Container behind a Durable Object, metadata checkpointed to R2, labelled preview70, BY0Planned
OpenTofu modules per cloud and tier, and a loams byoc deploy command70, BY1Planned
Container services (ECS Fargate, Cloud Run, Container Apps) as a checkpointed single node70, BY1Planned
loams backup into your own bucket70, BY1Planned
The loams-operator and a Helm chart on EKS, GKE and AKS65, 70, BY2Planned
Managed metastores: DynamoDB, Cloud SQL or Azure Database for PostgreSQL, Durable Objects on Cloudflare70Planned
App BYOC: apps and agents on each cloud's serverless free tier, with loams app deploy71Planned
Void for apps on Cloudflare, and Void's Node build on Vercel and the other clouds, with Vite+ as the toolchain79Planned
The gateway's edge listener for callers off the tailnet, such as apps on Vercel or Workers69Planned
Loams Cloud: a free, invite-only try-out that joins your own devices for development78Planned

Design 78 sets the order the deploy targets arrive in: TiDB X for development state, then Cloudflare, Vercel, AWS, Google Cloud and Azure, with AWS, Google Cloud and Azure as the production targets. The plan says production goes into your company's own cloud account, and development runs on your own devices.

On this page