European Serverless Functions With Lambda-Class Speed

A function that nobody’s calling should cost nothing and still answer the moment someone does. That’s the whole design brief for serverless, and it’s the thing most EU teams quietly give up when they pick AWS Lambda for data-residency reasons and pick a US-hosted alternative for speed. You shouldn’t have to choose. As of this week, orkestr Functions runs on a new serving engine that gets you both: EU-only infrastructure and cold starts you’d expect from Lambda itself.

What changed

Every function now runs in its own hardware-isolated micro virtual machine instead of sharing a kernel with other tenants. That’s not a cosmetic change - it’s what let us rebuild the whole path from “request arrives” to “your handler runs.”

The numbers we’re seeing in our own measurements this week:

• Cold start: ~500ms - a function that’s scaled to zero, answering its first request. Part of what makes that number possible is pre-warmed capacity: your function claims a slot that’s already running instead of booting one from nothing.
• Warm request: ~100ms end to end, including the network hop.
• Deploy: ~1 second from “save” to live code. No build step, no image, no restart. Editing a function feels like saving a file, because that’s close to what it actually is now.

Scale-to-zero is still the deal: a quiet function costs nothing and stays reachable. The difference is what happens the moment it wakes up.

Idle costs nothing. A cold request claims capacity that’s already running; a warm one goes straight to your code.

Isolation without the container next door

Functions on orkestr each get their own micro VM - a real kernel, its own memory, walled off from every other tenant’s code. That’s a stronger boundary than a shared-kernel container, and it’s the same property we use for the platform’s other isolated workloads. You get that boundary by default, not as an add-on.

Logs that survive scale-to-zero

The quiet failure mode of scale-to-zero platforms: your function winds down and takes its logs with it. That’s fixed. Every run of your function - from the moment it wakes to the moment it goes back to sleep - is now its own log stream in the console’s Logs tab. If you know CloudWatch, it’s that experience, without wiring up a separate logging service.

The currently running instance streams live at the top; past runs sit below it. Each stream shows the instance, its time window, why it ended (“scaled to zero”, “redeployed”), and everything your function said while it was up: your prints and errors, a line per request with status and duration, and a cold-start marker showing how long your code took to load.

Retention follows your plan: 1 day on the free tier, 7 days on Pro, 30 days on Team and up.

The honest comparison with Lambda

We’re not going to pretend AWS Lambda is bad - it isn’t, and if you don’t care where your data lives, it’s a mature, well-documented platform with a huge ecosystem. Here’s where the two actually differ, measured fairly:

	orkestr Functions	AWS Lambda (Python)
Cold start	~500ms	~200-400ms
Warm request	~100ms	~50-150ms
Deploy time	~1s (no build, no image)	30-60s for a container-image deploy
Hosting	Germany, Finland, France	Region of your choice, often US-adjacent control planes
Data residency	EU by construction	Depends on region + provider terms
Isolation	Micro VM per function	Micro VM per function

Lambda still wins the raw cold-start number if you’re not shipping a container image - that’s the mature, single-tenant-per-execution-environment model AWS has refined for a decade, and their own docs on execution environment reuse explain why warm paths are so fast there too. Where orkestr pulls ahead is the deploy loop: no container to build, no image to push, no cold restart of your CI. If you’re iterating on a webhook handler ten times an hour, a 1-second deploy versus a 30-60 second one adds up to real hours back over a week.

The pitch isn’t “AWS is bad.” It’s that you no longer have to trade EU hosting for Lambda-class performance to get it.

Why the EU part actually matters

Everything runs on servers in Germany, Finland, and France - Falkenstein, Helsinki, the usual EU-hosted providers, not a US hyperscaler anywhere in the request path. If you’re a startup that’s already been through the “can we actually use this vendor” conversation with a customer’s legal team post-Schrems II, you know why this is the first question, not the last one. No US data transfer to explain away, no sub-processor chain that ends in Virginia.

That’s not a checkbox feature bolted onto a US product for the EU market. It’s the whole infrastructure.

What’s supported today

Python and Node.js. Python went first; Node.js is landing on the new engine right behind it, with the same numbers - same cold starts, same ~1s deploys. Dependencies work the way they already do on Functions: paste a plain list of packages (pip requirements syntax for Python, package names or a full package.json for Node) and they install on deploy.

Functions exist on every plan, including the free one. The new engine is the same for all of them - what differs by plan is how many functions you get and how much CPU/memory each one has. Current limits are on the pricing page.

Trying it

The new engine is rolling out across existing functions now - there’s nothing you need to migrate or change, and your function’s URL and API keys stay exactly as they are. If you’re starting fresh, create a function from the Functions tab of the console; the default handler is a working example you can deploy unchanged to see the cold start for yourself.

If you’ve been holding off on serverless because “fast” and “EU-hosted” felt like a contradiction, this is us closing that gap.

FAQ

Is orkestr a real alternative to AWS Lambda for EU teams? If your priority is EU-only hosting with performance in the same class as Lambda, yes. If you need Lambda’s specific ecosystem (Step Functions, EventBridge, the full AWS service mesh), orkestr Functions is a simpler, HTTP-triggered tool, not a drop-in replacement for a deep AWS stack.

How much slower is a cold start compared to Lambda? Roughly the same order of magnitude - around 500ms on orkestr versus 200-400ms for a typical Python Lambda. The gap narrows once you’re warm, and disappears on deploy speed, where orkestr is faster.

Does this replace container app deployments on orkestr? No. Functions are for small, stateless HTTP handlers - webhook receivers, glue endpoints, small JSON APIs. Full apps still deploy as containers through the regular pipeline.

Is Node.js supported yet? Yes. Node.js is rolling out on the new engine right behind Python, with the same performance characteristics - same cold starts, same ~1s deploys. npm dependencies work the same way pip ones do.

Do logs disappear when a function scales to zero? Not anymore. Each run becomes its own browsable log stream, with your output, per-request status and duration, and a cold-start marker. Streams are kept for 1 day on the free plan, 7 days on Pro, 30 days on Team and up.

Where does the data actually live? On EU servers - Germany, Finland, and France today. No US cloud provider is in the request or storage path.