Introduction
In August, we described how we planned to approach migrating our Functions platform to Fission [1]. Today we can report: it is done. The migration to serverless-v4 is complete, all productive Functions on functions.evrtng.cloud run on the new platform, and the old OpenWhisk stack is out of service. For context on the series: Article 1 explained in March why we chose Apache OpenWhisk back then, Article 2 in August covered the technical deep dive of the migration itself [4]. This article is for you. We summarize what changes for you as a customer of evrtng Functions, what you get now that you did not get before, and why we accepted some uncomfortable decisions so your code ends up simpler than it started.
Where We Started: a Foundation Without a Future
Honestly: we would not have moved if there had been an easier path. The engine behind our previous platform, Apache OpenWhisk, did not evolve the way a production operation needs over the years. The Pekko fork we ran as a bridge has meanwhile landed in the ASF Attic, the archive for retired Apache projects. Building on a dead foundation would have been irresponsible toward our customers: no security updates, no further development, no support if something breaks. Staying would have been convenient in the short term, but a long-term risk we did not want to hand to you.
So we bet on Fission v1.27.0 [2], an actively maintained, Kubernetes-native engine with a healthy community. For you this means above all one thing: your Functions run on a platform that keeps being built, with regular updates and an operation that is not permanently fighting its own foundation.
Security: Every Invocation in Its Own Virtual Machine
The most important result of the migration is not a feature for us, it is a guarantee. On serverless-v4, every single Function invocation runs in a Firecracker microVM [3], operated via Kata Containers. Firecracker is the same technology that powers serverless platforms at the large cloud providers. The difference to classic containers: a microVM is a real virtual machine with its own kernel. Your code and your data are separated from other tenants at the hypervisor level, not just at the container level.
What this means for you concretely: the isolation of your workloads matches that of a dedicated virtual machine, without you managing one. You configure nothing, you switch nothing on. This isolation level applies to every invocation, for every Function, on every plan. Additionally, Function executions run on their own dedicated cluster nodes, fully separated from the rest of the platform. Your executions share hardware with other Functions, but never a kernel.
Speed: Warm Pools Instead of Cold Starts
Isolation alone is not enough if every request answers sluggishly. That is why we introduced warm pools. Frequently used Functions stay preloaded and wait for the next invocation instead of starting fresh on every request. We shortened the path from incoming request to response because no container is created and destroyed per call.
You notice this most with Functions that are called regularly, for example inside an integration or behind a webhook: they respond quickly, without a cold-start pause. Irregularly used functions benefit too, because warm instances refill faster than before. Your benefit: short, predictable response times in day-to-day operation, without any tuning on your side.
The New API: Simpler to Write, Clearer to Read
We deliberately made a clean cut and simplified the Function API. The new signature is a single, obvious form:
// New - serverless-v4
module.exports = async function(ctx) {
const name = ctx.body.name || "world";
return { status: 200, body: { message: `Hello ${name}` } };
};Three changes in summary: the entry point is now module.exports, the argument is a context object instead of just the parameters, and the response uses status instead of statusCode. The public path is /fission-function/*.
This is a breaking change, and that was intentional. We could have built a compatibility layer that keeps both API worlds alive. We chose the clean cut instead: adapt once, briefly, and it stays simple forever. Compatibility layers would have become permanent work, with sources of errors that you would have ended up paying for. If you are bringing Functions over from v3, adapting the entry point takes minutes. We described the migration steps in the August article [4], and our support team accompanies the transition if you have questions.
Multi-Tenancy: Guaranteed Resources, No Noisy Neighbors
On a shared platform, the classic worry is: what happens when another tenant eats all the resources? We answered that question technically before it becomes your problem. Every tenant on serverless-v4 is managed as its own object, a so-called FissionTenant, with its own quotas and its own separation at the Kubernetes level. Limits apply per tenant, not globally.
Your benefit: the resources that match your plan are guaranteed. A neighbor with load spikes cannot throttle your Function, because their executions are cleanly separated from yours and their quotas stay their quotas. That is the difference between shared on paper and actually guaranteed. For teams running multiple environments, the strict separation adds another advantage: production and experimentation do not get in each other’s way.
Billing: Traceable Down to the Single Invocation
We built the billing ourselves so that it is traceable. Usage is billed in GB-seconds (GBS): memory footprint times runtime, summed over the billing period. Every single invocation is logged: our API gateway writes a log entry for every request with path, status, latency, and tenant, which flows straight into our billing pipeline and is processed there into your invoice.
For you this means: you pay exactly for what you use, not for a flat estimate. And you can verify it. If an invoice raises a question, every amount rests on a logged invocation list. No black box, no mysterious usage figures, but entry by entry. We deliberately took this transparency into our own hands instead of forwarding opaque third-party usage numbers.
Operated in Switzerland
Sovereignty is not a marketing term for us, it is an operational fact. The platform runs entirely in Switzerland. Your code stays in Switzerland, your data stays in Switzerland, and the operation uses the same proven cluster tooling as before. For customers with data locality requirements, this is probably the calmest line in this article: nothing leaves the country, nothing has to.
Decisions We Made for You
Complex migrations consist of dozens of small decisions. Four of them shaped the result, and each was made with you in mind.
An actively maintained platform instead of an archive. We left OpenWhisk because its fork was dead. Staying would have been convenient in the short term. In the long term, you would have stood on a foundation without updates. Fission is actively developed [2], you benefit from security updates and new features without lifting a finger.
A clean break instead of eternal baggage. We accepted the breaking change of the new API so that the API stays simple forever after. Maintaining two signatures in parallel would have produced a permanent stream of error sources. It stings briefly, then the air is clear: one obvious way to write Functions.
Running microVMs ourselves. Operating Firecracker microVMs yourself is complex, and it was the most demanding part of the migration. We took on exactly that complexity so you get VM isolation without managing virtual machines yourself. You write Functions, we take care of hypervisor, kernel, and operation.
Self-built billing instead of a black box. We could have simply output aggregated usage data. Instead we built a pipeline that logs every invocation individually, so your billing remains verifiable down to the last second of compute time.
Outlook
The migration is complete, the build-out continues. The self-service portal is live: tenants are created automatically at registration, and you change quotas yourself through your subscription – no support needed. Next up are improvements to the trigger types and to the developer experience, so you get from idea to running Function even faster.
What you should do now: if you are still running v3 Functions with the old signature, adapt them to the new API. The steps are in the August article [4], and it takes minutes per function. Our support team is there if you have questions. Thank you for moving with us. Your Functions now run on a foundation that holds: securely isolated, fast enough for everyday work, transparently billed, and everything in Switzerland.
- August strategy article: https://evrtng.cloud/2026/08/15/serverless-computing-2026-update/
- Fission v1.27.0: https://fission.io
- Firecracker microVM: https://firecracker-microvm.github.io
- Article 2 (migration deep dive): https://functions.evrtng.cloud/en/2026/08/18/how-we-migrate-to-fission-serverless-v4/
