Aseptic vs Telepresence
Telepresence and Aseptic agree on the diagnosis —you should not have to run twelve services to work on one— and disagree on where the other eleven should live. Telepresence borrows them from a cluster. Aseptic lets you decide one by one.
In one sentence
Telepresence connects your machine to a Kubernetes cluster and intercepts the traffic of a chosen service, routing it to the copy you are running locally. The rest of the system stays in the cluster, real, and your process talks to it as if it were deployed there.
Aseptic starts the services of a scenario on your machine and resolves each dependency to a local service, a shared cloud environment or a mock, rewriting the URLs between them at startup. No cluster is involved.
The table
| Telepresence | Aseptic | |
|---|---|---|
| Needs a Kubernetes cluster | Yes, and one that is deployed and healthy | No |
| Where the rest of the system runs | In the cluster, real | Wherever you choose, per dependency |
| How many services you run locally | Typically one, the intercepted one | As many as the scenario says |
| Realism of the dependencies | Very high — they are the real ones | As high as you point them; mocks are also an option |
| Works offline | No | Yes, unless a dependency points to the cloud |
| Risk to shared environments | Real — you are inside one | None by default; only if you point a dependency there |
| Shared infrastructure for the flow | The cluster's | Kafka, Redis and PostgreSQL brought up in Docker for you |
| Licence | Open source core, commercial tiers | Free for personal use, paid for commercial use |
Take Telepresence if…
- The bug only shows up against the real thing: real data volumes, the real identity provider, the real gateway in front.
- Your system is far too large to run on one machine and always will be.
- You already keep a shared development cluster that reflects reality closely enough to be worth borrowing from.
- You are changing one service and the rest is not in play.
Take Aseptic if…
- You want to change several services at once and see the flow end to end, which an interception of a single service does not give you.
- You want to work on a plane, on a train, or on a day when the shared cluster is down.
- You would rather not have your half-written code inside an environment your colleagues are using.
- You want the choice: this dependency local, that one against the cloud, this third one mocked — and to change it in a click.
Where Aseptic falls short
Realism. Telepresence's dependencies are the real deployed services with their real configuration; Aseptic's are whatever you pointed them at. If the failure you are chasing lives in that gap —a difference in the cluster's networking, a header the gateway adds, a payload nobody documented— the local copy will not reproduce it, and hunting it there wastes an afternoon.
Aseptic is also in public beta, ships for Windows, macOS and Linux, and it is not open source.
What usually ends up happening
These two coexist better than most: Aseptic for building the feature, Telepresence for the last mile against the real environment when something does not add up. And worth saying plainly, since Aseptic can point a dependency at your shared environment too: that is a URL, not an interception. It is simpler and it is also less faithful.
If the cluster is what you are comparing, see Tilt, DevSpace and the wider comparison.
Frequently asked questions
What does Telepresence actually do?
It connects a process running on your machine to a real cluster, so that your local service takes the place of the deployed one and talks to the rest of the cluster.
So why is Telepresence not enough?
Because it needs the cluster. If it is down, if you have no VPN, or if you want to run three services at once without touching the shared environment, that model does not help. Aseptic runs the whole flow on your machine and points each dependency where you choose.
Can I mix local and remote services with Aseptic?
Yes, and it is the whole point: for each dependency you decide whether it goes to the local service, to your cloud environment or to a mock.