OSC Now Runs Fully on Swedish Infrastructure
For a broadcaster, a public-sector customer, or anyone with a data-residency clause in their own contracts, "where does this actually run" is not a rhetorical question. Open Source Cloud now runs fully on Swedish infrastructure, Swedish-owned, in Stockholm, with no US hyperscaler in the stack. This is the result of a signed contract, not a marketing decision, and this post says plainly what has moved and what has not.
For a broadcaster, a public-sector customer, or anyone with a data-residency clause in their own contracts, "where does this actually run" is not a rhetorical question. As of this week we have a concrete answer for Eyevinn Open Source Cloud: OSC runs fully on Swedish infrastructure, Swedish-owned, in Stockholm, with no US hyperscaler in the stack.
A contract, not a marketing decision
Eyevinn signed with Elastx on 2026-09-10, executed and countersigned the same day, moving OSC production compute off any hyperscaler dependency. The technical cutover to prod-se as primary has been live on the wire since 2026-08-25. The contract that makes the arrangement durable, with a three-month notice period and no binding-period discount taken, closed this week. The order matters: the infrastructure moved first and was proven in production, and the paperwork followed.
What this changes for you
If a vendor questionnaire, a public tender, or your own downstream customer asks where OSC infrastructure sits, the honest answer is now a single Swedish provider rather than a mix that includes a US hyperscaler EU region. We are not claiming this makes OSC GDPR-compliant on its own, because that was never the gap. We are stating a specific, verifiable fact about where the compute runs, because for some of you that fact is the actual blocker in a procurement conversation rather than a preference.
What has not moved yet
Said plainly rather than left for you to discover: our development environment remains outside this cutover, and it is the only exception — our staging environment was decommissioned separately and no longer exists on any provider. This post is about the production Swedish-infrastructure claim specifically. It is not a claim that every operational surface has migrated, and we would rather name the exception than let a headline overstate the position.
See for yourself
Every service in the OSC catalog is open source, so the portability argument is unchanged by any of this: the same workloads run on another cloud or on your own hardware whenever you decide to move them. Changing where we run does not change your ability to leave.
Frequently Asked Questions
Does this mean OSC is GDPR-compliant?
No, and we are deliberately not making that claim. Where compute runs is one input to a data-protection assessment, not the whole of it, and residency was never the only gap. What changed is a specific, verifiable fact: OSC production compute runs on a single Swedish-owned provider in Stockholm rather than on a US hyperscaler region. For some procurement conversations that fact is the actual blocker, which is why it is worth stating on its own terms.
Which provider, and since when?
Elastx, a Swedish-owned provider in Stockholm. The technical cutover to prod-se as primary has been live on the wire since 2026-08-25. The agreement that makes the arrangement durable was executed and countersigned on 2026-09-10, with a three-month notice period.
Is every part of OSC on Swedish infrastructure now?
Not quite, and the remaining list is one item long. Production compute is, and so are the UDP-based services and our mail-server solution. What sits outside this cutover is our development environment — our staging environment was decommissioned separately and no longer exists on any provider. We would rather name it than let a headline imply a completeness we have not reached.
Can I still move off OSC if I want to?
Yes, and that is the point of the architecture rather than a concession. Every service in the catalog is open source, so the same workloads run on another cloud or on your own hardware. Changing where we run does not change your ability to leave.
Related Posts
Your Vibe-Coded App Deserves Better Than a Credit Tax
Credit-based AI builders charge per generation. When free tiers expire, real costs emerge. Deploy your vibe-coded app on real infrastructure, no credits, no counter.
Your Agent Doesn't Just Deploy the Backend. It Can Run It.
Most agent-infrastructure stories stop at "the agent deployed it." A real run this week went further: an agent uploaded, packaged, and delivered a review copy, then reported an operational mistake nobody asked it to check. Here is why that only works when the agent is calling real, unmodified open-source APIs.
From Vibe Coding to Agentic Engineering: What Your Infrastructure Needs to Keep Up
Vibe coding gets you to a working prototype fast. Agentic engineering gets it to production and keeps it there. Here is what the infrastructure gap looks like up close.