Stop Killing Games Lost Both Votes in June 2026: What Actually Protects Your Game Now
The EU Commission answered Stop Killing Games on 16 June 2026 and refused a legal obligation to keep games playable, citing copyright. California's Protect Our Games Act died in Senate committee two weeks later on 4-3 with four abstentions, and cannot return until 2027. No law is coming. That makes backend continuity a purchasing decision, so here is how to audit any backend for it, including ours, honestly.
For about two years, the honest answer to "what happens to my game when the backend goes away" included a hopeful clause: and there may be regulation coming. In June 2026 that clause stopped being true, twice, about two weeks apart.
This matters for anyone shipping an online feature, so it is worth stating the outcomes precisely rather than through headlines.
What actually happened in June 2026
The EU route closed on 16 June. The Stop Killing Games European Citizens' Initiative collected 1.29 million verified statements of support and submitted them on 26 January 2026, clearing the million-signature threshold that obliges the Commission to examine the demand and reply in public. The reply, when it came, declined to propose a legal obligation on publishers to keep games playable after commercial end-of-life. The stated barrier was intellectual property and copyright. In place of legislation the Commission committed to beginning an industry code of conduct process by the end of 2026, and to raising awareness of consumer rights that already exist under the digital content directive.
It is worth being clear about what a code of conduct is: an agreement the industry writes about itself, that it opts into, and that nobody can sue over. It may still be useful. It is not the thing 1.29 million people signed for.
The California route closed at the end of June. AB 1921, the Protect Our Games Act, introduced by Assemblymember Chris Ward, took a narrower angle than the EU initiative: rather than mandating that games stay playable forever, it would have required publishers to warn players before shutting down a paid online game and to offer either refunds or continued access. It cleared the Assembly appropriations committee in mid-May over objections from the Entertainment Software Association, which was a genuine surprise. Then it failed in a state Senate committee: four votes in favour, three against, and four abstentions. It needed a majority, and abstentions do not count toward one. Reconsideration was granted, but procedural deadlines mean the bill cannot come back for a vote until the 2027 session.
That detail is the one worth sitting with. The bill was not defeated by a wall of opposition. It was defeated by four people declining to vote at all, which is a much cheaper thing for a lobbyist to arrange than seven no votes.
What this changes for you, concretely
Nothing about the technical risk changed in June. What changed is that the risk is now definitively yours to manage rather than something a regulator might absorb on your behalf. Until at least 2027 in California, and until a voluntary code exists and proves itself in the EU, the continuity of your online features rests entirely on decisions you make before you integrate.
We have written about the shutdown wave itself elsewhere, because it has been relentless: Hathora and Unity Multiplay hosting both sunset in 2026, SilentWolf went dark in late 2025 and broke leaderboards in Godot games that had already shipped, and PlayFab introduced a new Xbox-linked Foundation Mode alongside its limited Development Mode and metered plans. None of those changes were covered by preservation proposals aimed at publishers switching off games sold to players.
That last point deserves emphasis, because it is the part the coverage mostly missed. Even if both measures had passed, neither would have protected you from your backend vendor. Both were aimed at publishers switching off games they sold to players. Your dependency is one layer below that: a service you buy, that your game needs, whose disappearance breaks your game without anyone shutting your game down. There was never a bill for that, and there is not one now.
The audit that replaces the law
Since the protection is not coming from legislation, it has to come from procurement. These are the questions worth answering before you write code against any backend, ours included. They are all checkable in an afternoon, and none of them require a sales call.
1. Can you export everything, today, without asking permission?
Not "is there an export feature on the roadmap", and not "will support generate a dump on request". Can you, right now, with credentials you already hold, pull every player record, every save document, every leaderboard entry, and every piece of economy state, in a format you can read? If the answer requires a human at the vendor to cooperate, then your continuity plan depends on that human still working there on the worst day.
The cleanest version of this is when the read API is the export tool: if every write has a corresponding documented read, then export is just a loop you can write yourself and test today rather than trusting later.
2. Is the API documented well enough to reimplement behind?
A documented HTTP API is the difference between migrating and rewriting. If your game talks to a proprietary SDK with undocumented wire behaviour, then replacing the backend means touching every call site in a shipped build. If it talks to documented HTTP, you can point a shim at a replacement and ship a patch. Ask for the OpenAPI spec. If there is not one, that is your answer.
3. What has the vendor committed to in writing about notice?
Terms of service almost always let a provider terminate with minimal notice. That is normal and not itself alarming. The question is whether there is anything beyond the terms of service: a published policy stating how much warning you get and how long export stays available after a shutdown decision. Most vendors have nothing. A few have something. It costs you one page-load to find out which.
4. What happens to your data if you stop paying?
Distinct from shutdown, and more likely to affect you. If your game has a quiet month and you drop below a threshold, or a free tier gets restructured the way PlayFab's was, does your data get archived, frozen, or deleted, and how much notice comes first? This is the failure mode that actually strands small studios, and it is usually buried.
5. Is there an escape hatch that does not depend on the company existing?
Self-hostable code, or an open protocol, or at minimum a documented schema for the export in question 1. This is where open source genuinely helps, and it is also where open source gets oversold: the code surviving does not help if your live data is stuck in someone else's database. You want both.
Where Crux stands, including where it does not
We build a game backend, so treat this section with the scepticism it deserves and check the claims rather than taking them.
On question 1, our read API covers everything our write API covers, which is a deliberate design choice and the thing that makes export self-serve rather than a support ticket. On question 2, there is a published OpenAPI spec and the SDKs are MIT-licensed, so the wire format is inspectable and reimplementable. On question 3 we publish a written commitment rather than leaving it to the terms of service. On question 4, the free tier is a real tier rather than a trial that expires.
On question 5, here is the honest gap: Crux is not self-hostable today. The SDKs are open source; the server is not. If we disappeared, you would have your data and a documented API to rebuild against, which is meaningfully better than nothing and meaningfully worse than being able to run the thing yourself. Anyone telling you that a hosted backend has no continuity risk is selling you something.
And the obvious point that a vendor is never keen to make: we are small. Small companies fail more often than Microsoft does. The argument for us is not that we are guaranteed to outlive PlayFab, because we are not. It is that the cost of us being wrong is bounded by what you can export, which is why we would rather you evaluate us on question 1 than on our optimism.
The takeaway
Two legislatures looked at the question of whether players and developers should be protected when online games and the services behind them get switched off. One said the copyright framework prevents it. The other could not assemble a majority because four senators abstained. Both outcomes landed in June 2026, and neither is likely to be revisited before 2027.
So the practical answer to "what protects my game" is now short, and it has not changed in a decade: an export you have actually tested, and an API you could rebuild behind. Everything else, including our guarantee page and everyone else's, is a promise about the future made by a company that might not have one. The export is the only part that is yours.
Related reading
- Will your game backend still be alive next year? - the four-question continuity checklist in full.
- The 2026 game backend shake-up - who died, when, and where studios actually went.