Vulkan Cloud

Everything in Vulkan is open source and always will be. Vulkan Cloud is for teams who want the platform without owning its operations — the same engine, plus the tooling that turns “we can see everything in SQL” into “everyone on the team does see everything, on a dashboard, with alerts.”

cloud.vulkan.dev/acme/streams/orders

acme / streams / orders live

Throughput

12,481/s

Max lag

142

fraud-screening

Dead letters

2

triage →

Oldest unacked

3.2s

healthy

CONSUMER GROUPMODELAGDLQRATE

email-receiptslifecycle001,240/srewind

fraud-screeninglifecycle1422 ⚠643/sredrive

warehouse-synclifecycle370982/srewind

search-indexercursor · replaying1.2M ↓—9,410/spause

⚠ fraud-screening DLQ grew +2 in 10 min — notified #oncall

One screen answering the four questions that operate any messaging system: is work flowing (throughput per group), is anyone falling behind (lag, with replaying groups clearly marked), is anything dying (dead letters, with payloads and one-click redrive), and is anything stuck (oldest unacked age, hot partition keys).

What’s in the box

Managed Postgres or bring your own

Run on our managed, queue-tuned Postgres — or point Vulkan Cloud at your existing database and keep your data exactly where it is. Your messages never have to leave your VPC.

Audit log & team access

SSO, per-environment roles, and a full audit trail — every redrive, rewind, and retention change recorded with who, when, and how many messages it touched.

Replay console

Rewind any consumer group to an offset or a timestamp from the UI. Dry-run first to see exactly what would be redelivered.

Dead-letter triage

Inspect payloads and error history, fix the bug, then redrive one message, a filtered set, or the whole DLQ — with one click.

Alerting that knows queues

Lag exceeding retention, DLQ growth, a consumer group gone quiet, a hot partition key serializing your throughput — alerts on the failure modes that actually happen, wired to Slack or PagerDuty.

Retention & lifecycle policies

Set retention per stream in the UI. Partition-drop cleanup (not mass DELETEs), archive-to-S3 for cold history, and automatic index health.

How it’s priced

Simple and aligned with the open-source promise:

	Open Source	Cloud Starter	Cloud Pro
The full engine	✅ free, forever	✅	✅
Streams & consumer groups	unlimited	unlimited	unlimited
Dashboard, replay console, DLQ triage	—	✅	✅
Alerting	—	basics	full, custom rules
Managed Postgres	—	shared	dedicated, queue-tuned
Bring-your-own database	n/a	—	✅
Support	community	email	priority + shared Slack
Price	$0	$29/mo	usage-based

No semantic lock-in

Cloud runs the same open-source engine and the same schema. Leaving Vulkan Cloud is pg_dump, not a migration project. We think that’s the only honest way to sell open-source infrastructure.

The dashboard shows its work

There’s no proprietary metrics layer underneath any of this — every panel is a SQL query against the same tables your application uses, and clicking any panel reveals the query behind it. The lag chart is a subtraction; the DLQ panel is a WHERE status = 'dead'. That means nothing the dashboard knows is hidden from you, and everything it knows works in psql, Grafana, or a cron job too.

It also means the dashboard can answer questions broker consoles can’t, because your messages live next to your business data:

-- "Are all the dead fraud-screening messages from one merchant?"
SELECT o.merchant_id, count(*)
FROM vulkan.deliveries d
JOIN vulkan.events e ON e."offset" = d.event_offset
JOIN orders o ON o.id = e.payload->>'order_id'
WHERE d.consumer_group = 'fraud-screening' AND d.status = 'dead'
GROUP BY 1 ORDER BY 2 DESC;

The line we won’t cross

Features that change what your code can do — transactional enqueue, replay, fan-out, routing, FIFO — are open source, always. Cloud sells operations, not capabilities. If you ever find a semantic feature behind the paywall, file an issue titled “you broke your promise.”