Three emulators. One box.
An application sits on three things it did not write: a network, a cloud control plane, and somebody else’s API. Labtris emulates all three on hardware you own, so the whole stack can be stood up, broken on purpose, and thrown away.
Two of the three exist today. The third does not, and is marked as such below.
Network Emulator
ShippingThe core product, and the reason the other two have somewhere to run. Containers and KVM guests wired over Linux bridges, taps and veths — the kernel’s own forwarding path, not a model of it.
- Containers and QEMU/KVM virtual machines on the same canvas
- FRR routing, BGP EVPN, VXLAN, VLAN-aware bridges
- Generated spine-leaf, fat-tree and rail-optimised fabrics
- P4 dataplanes on bmv2, DCB and PFC queueing
- Link impairment, packet capture, a Wireshark GUI in the browser
- Serial, VNC and RDP consoles; an SSH proxy per node
MIT licensed. No node cap, no licence server, no account. It stays that way. The repository is private during the beta — access is by invitation.
Cloud Emulator
Shipping — AWS onlyThe AWS API surface, served from the same box, so an application under test talks to S3 and DynamoDB without touching an AWS account. Point any SDK at it — the CLI, boto3, Terraform’s hashicorp/aws provider, Pulumi, Ansible.
Twenty-four AWS services are real here — the ones below. Each was round-tripped with a real client against a live backend and stamped by a test, rather than asserted.
That matters most when something other than a person is driving. An agent can build your software and run the whole suite against these services as often as it likes: no AWS bill, no rate limits, no credentials that could reach production, and nothing it does leaves the box. Dedicated hardware you own, where the thousandth run costs what the first one did.
The registry reaches wider than these twenty-four, and which service becomes real next follows what people actually need. If the one you depend on is not in the list, say so at [email protected] — that is how the order gets set.
- S3
- DynamoDB
- RDS
- ElastiCache
- SQS / SNS
- Lambda
- Route 53
- OpenSearch
- DocumentDB
- Redshift
- MQ
- MSK / Kinesis
- CloudWatch Logs
- CloudWatch metrics / Timestream
- Neptune
- Secrets Manager / KMS
Azure, GCP and OCI are planned, not written. The service registry is already keyed by provider, so they are a matter of writing services rather than rearchitecting — but nothing ships today beyond AWS.
Not open source. The Cloud Emulator is a separate, commercial product, in its own repository. The MIT terms cover the network emulator and nothing else — installing Labtris does not get you this. Write to [email protected] for access.
App Emulator
Not startedThe layer above the cloud: the third-party APIs an application calls but cannot run — a payment processor, a git forge, a storefront. Today those are mocked by hand in every test suite that needs them, and the mock drifts from the real thing.
This does not exist. There is no code for it, no release date, and no commitment to one. It is on this page because the shape is already there — the registry that serves AWS is keyed by provider name, and the backing system that gives S3 a real SeaweedFS behind it does not care whether the API in front is AWS-shaped or not.
When it is built, it will be built here — in the same registry as the Cloud Emulator, backed the same way, and held to the same tier rule that a service is not claimed until a real client has round-tripped it. Not an integration of somebody else’s twin service bolted on beside the cloud one. It will be commercial, like the Cloud Emulator, rather than MIT.
The honest constraint: the hard part of the Cloud Emulator was never the plumbing, it was protocol fidelity, one service at a time. Every SaaS API brings its own version of that problem. If this is something you would use, the contact address is where to say so — it is the only thing that will move it up the list.