Disposable infrastructure for CI and integration testing

Integration tests need real services, not mocks, but shared test databases drift and leak data. Create a fresh, isolated service per test run and let it delete itself.

What problem does it solve?

A CI job that needs object storage, a database or a mail inbox usually shares a long-lived instance, so runs interfere with each other. MicroSaaS.app gives each run its own service with its own credentials and an expiry time.

How does a CI job use it?

Three steps, all with the msaas command line tool or the REST API.

msaas create redb-kv --ttl 1h --wait --json

Is automatic expiry real?

Yes. The API enforces the time to live and the control plane deletes expired services; this was verified end to end in automated tests against the control plane. On the production microVM runtime, a scheduled absolute delete removed a running instance at its scheduled time, and an idle-based delete removed a standby instance within 20 seconds (tested 2026-10-29).

Which services fit?

Services that fit CI and integration testing
ServiceFloorStatus
Object storage64 MBValidated
Key-value store64 MBValidated
SurrealDB96 MBValidated
libSQL64 MBValidated
Analytical SQL128 MBValidated
Messaging64 MBValidated
Mail inbox64 MBValidated
Push relay64 MBValidated
Webhook capture64 MBValidated
Container registry96 MBValidated

Floors are the smallest tested memory, not sizing advice. How we measure. Pricing.

Last updated