- web
- database
- cache
- has storage
| Instance | Role | Storage | State |
|---|
Live demos
Two isolated environments. Pick one.
What you get
- Distribute. Place redundant web, database, cache, and workers across nodes — the live topology shows where every instance runs.
- Rebalance & recover. When an instance or node fails, replicas and mesh peers keep serving. Standbys, read paths, and workers keep the stack moving.
- Ensembles. One YAML file groups interdependent services with shared lifecycle, startup order, and network aliases — then you scale out the instances.
- Muscle memory. create · run · stop · logs · ensemble — keep the workflow you know, on native BSD without a Linux guest VM layer.
How the parts fit
OCI image in, native BSD out. Spread ensembles across nodes — distribute, rebalance, recover.
Namespace → Pod → Ensemble
Namespace and pod labels on every ensemble. Omit them and Aeolus fills defaults so existing YAML keeps working.
- Namespace label scope for ensembles (default: default)
- Pod label for the stack unit; default {ensemble}-default when omitted
- Ensemble multi-service stack in one YAML file
- Ladon clustered secrets — ladon.revytechinc.com
- CloudBSD demo images build recipes at cloudbsdorg/aeolus-examples
Image → CLI → native BSD
Open the ensemble
An ensemble is one YAML file that declares a multi-service stack — web, database, cache, and friends — with shared lifecycle so Aeolus can distribute, rebalance, and recover the whole unit.
Declare once, scale with replicas. Storage pools hold durable data; instances attach by volume name. Standbys and read paths keep recovery honest.
# CloudBSD demo images — see github.com/cloudbsdorg/aeolus-examples
version: "1.0"
name: aeolus-blog
namespace: demo
# pod omitted → aeolus-blog-default
volumes:
- name: db-data
pool: zfs/aeolus/blog
- name: wp-data
pool: zfs/aeolus/blog
services:
- name: db
image: ghcr.io/cloudbsdorg/aeolus-mariadb:16
replicas: 1
volumes: [db-data]
# secretRef: { ladon: demo/db/password } → Ladon cluster
- name: wordpress
image: ghcr.io/cloudbsdorg/aeolus-wordpress:16
replicas: 2
depends_on: [db]
ports: ["8080:80"]
volumes: [wp-data]
Two certificate planes
Node mesh (private)
An offline cluster CA issues node certificates. Nodes prove identity to each other — operators stay off the public CA.
Public names (Let’s Encrypt)
Product hostnames such as blog.aeolus.cloudbsd.ai present certificates browsers already trust.
How networking works
Publish a port, give services aliases, hit the product name from a browser. Map the same pattern onto your own nodes.
On your cluster: publish the service port, point DNS at the node that publishes it, and keep node-to-node auth on the private mesh CA.
On your cluster
Same muscle memory. Install the CloudBSD package that ships aeolus, then create, run, and ensemble.
# Single service
aeolus create --name api -p 8443:443 --memory 1G ./bundle
aeolus start api
aeolus ps
# Multi-service stack — same shape as ensemble.yml above
aeolus ensemble validate ./ensemble.yml
aeolus ensemble up ./ensemble.yml
aeolus ensemble status ./ensemble.yml
# Cluster mesh (nodes only — not for browsers)
aeolus cert bootstrap --cn cluster.example
aeolus cert issue-node n1
aeolus cert issue-node n2
- Install Aeolus from your CloudBSD package set.
- Bootstrap a private cluster CA and issue one cert per node.
- Run workloads with
aeolus runor group them withaeolus ensemble up. - Publish ports and attach public TLS only to the names browsers will open.
Live demos
Hit a running ensemble — same distribute → rebalance → recover story, public TLS: