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.
- Create the service with a time to live (whole hours, default 1 hour, up to the plan maximum) and read back the endpoint and credentials.
- Point the test suite at the endpoint.
- Do nothing at the end: the service is deleted at its expiry.
msaas create redb-kv --ttl 1h --wait --jsonIs 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?
| Service | Floor | Status |
|---|---|---|
| Object storage | 64 MB | Validated |
| Key-value store | 64 MB | Validated |
| SurrealDB | 96 MB | Validated |
| libSQL | 64 MB | Validated |
| Analytical SQL | 128 MB | Validated |
| Messaging | 64 MB | Validated |
| Mail inbox | 64 MB | Validated |
| Push relay | 64 MB | Validated |
| Webhook capture | 64 MB | Validated |
| Container registry | 96 MB | Validated |
Floors are the smallest tested memory, not sizing advice. How we measure. Pricing.
Last updated