Supabase Got Blocked in India
Your backend provider is one government order away from disappearing!
Hey everyone!
I’m back in your inbox and this time I want to talk about a problem that currently no AI in the world can fix for you - Government Block 🫠
In a week where AI is writing entire frameworks and doing code reviews from scratch (more on this in my next newsletter), thousands of developers in India watched their production apps die overnight not because of a bug in their code but because the government decided their backend provider shouldn’t be reachable anymore.
Supabase, the open-source Firebase alternative that thousands of Indian developers and startups rely on for their backends, was blocked in India for over a week. It was not a server outage, neither a misconfiguration but a government order.
The Indian government ordered ISPs to block it under Section 69A of the Information Technology Act.
Now this isn't a Supabase problem as it can happen with any platform such as Firebase, Codex, Cline, CodeRabbit or any other hosted developer service and the story reads the same way.
If your product depends on a third-party domain that a government decides to block, your app goes dark and there's nothing in your code you can fix. This could happen to any platform, in any country, and at any time.
If you build products on third-party platforms, regardless of where you or your users are, this one is worth reading. There are several layers to dig into here:
What actually happened → Supabase went dark for Indian developers, and the initial confusion lasted hours before anyone realised the problem wasn’t with Supabase at all.
The technical root cause → This wasn’t an infrastructure failure. It was ISP-level DNS blocking, and not a single AWS component went down.
Why the government won’t tell you the reason → Section 69A of India’s Information Technology Act gives the government power to block any online content, and the Supabase block broke production apps serving real users who had no idea what Supabase even was.
The real impact → India holds roughly 9% of Supabase’s global traffic. When the block hit, core backend services stopped working for apps across the country.
Supabase’s response and what it revealed → How do you communicate when your platform gets blocked by a government? Supabase’s evolving status page language over 8 days tells an interesting story.
How developers got around the block → Switching DNS or using a VPN helped developers get back to work, but none of that helps your end users, so the community had to get creative.
It’s unblocked → On March 4, 2026, about 8 days after the block was first reported.
What this changes about how you should build → Vendor lock-in now includes geopolitical risk, and most of us aren’t planning for it.
Stop debating architecture in pull requests.
If your team’s pull requests are filled with comments like:
This architecture won’t scale
We should approach this another way
You are suffering from high costs and wasted developer time.
Developers often realize what should have been built only after the PR discussion begins, leading to endless back-and-forth and complete rewrites.
Introducing CodeRabbit Plan that makes planning a first class workflow before you write a single line of code. CodeRabbit Plan lets teams design how a feature should be built before writing code, so PR reviews become validation instead of architecture debates.
Old Way: build > PR > debate
New Way with Plan: plan > align > build
(Thanks, CodeRabbit team for partnering on this post.)
1. What Actually Happened
On February 24, 2026, developers in India began reporting connectivity failures to Supabase services. API calls were timing out, authentication flows were breaking, and project dashboards wouldn’t load. The impact wasn’t uniform - it varied by ISP and region but the reports were widespread enough to make it clear something systemic was happening.
At first, most people assumed it was a Supabase outage but it wasn’t.
Supabase’s infrastructure was fully operational. The problem was on the ground, where major Indian ISPs including Jio, Airtel, and ACT Fibernet had received a government directive to block DNS resolution for *.supabase.co domains.
When app tried to reach project-name.supabase.co for anything, whether a database query, an auth call, or a storage request, the ISP’s DNS resolver would either return nothing or redirect to a dead-end IP address.
Here’s a list of every Supabase service that went dark for Indian users:
Database (PostgREST API): all queries, inserts, and updates failed
Auth (GoTrue): login, signup, and token refresh broke completely. Users couldn’t authenticate
Realtime: WebSocket connections couldn’t establish
Storage: file uploads and downloads became inaccessible
Edge Functions: all serverless functions unreachable
Dashboard: developers couldn’t even access their project management console
API Gateway: every REST and GraphQL call timed out
In short, if app touched Supabase in any way, it was dead.
The frustration was immediate. As the developer who opened the thread on r/developersIndia put it: Supabase had “suggested changing DNS or using a VPN, which is completely unviable for production apps with real users.”
What made this particularly confusing is that the marketing site (supabase.com) remained accessible while *.supabase.co (where all project infrastructure lives) was completely blocked.
The Supabase homepage loaded just fine while every project dashboard and API endpoint was dead. This distinction led to hours of unnecessary debugging before developers realised it wasn’t their code that was broken. It was their country’s network.
So if Supabase’s own infrastructure was running fine the entire time, what was actually breaking? The answer lies in how the internet routes traffic, and understanding it explains why none of the obvious fixes worked for production apps.
2. The Technical Root Cause: DNS, Not Infrastructure
Lot of the initial confusion came from people assuming AWS or Supabase’s infrastructure had failed. It hadn’t. Nothing inside AWS went down.
The block happened primarily at the DNS resolution layer, before traffic ever reached Supabase’s servers. The diagram below shows both paths - how the ISP block intercepted DNS resolution, and how switching to an alternative DNS provider bypassed it:
Multiple ISPs across India were returning incorrect DNS responses for *.supabase.co domains. In some reported cases, ISPs returned sinkhole IPs (redirecting to ISP-controlled addresses instead of Supabase’s actual servers), while other users reported getting no usable response at all. Either way, the user’s device couldn’t reach Supabase’s actual servers, so connections simply failed.
The original GitHub issue that first reported that a developer ran nslookup on their Supabase project domain from Jio’s network and got back 49.44.79.236 - an IP address belonging to Jio/Reliance, not AWS. A traceroute showed traffic dying within Reliance’s own network, never making it anywhere near Supabase’s servers.
Supabase runs its infrastructure on AWS, and the two regions closest to Indian users are AP-South-1 (Mumbai) and AP-Southeast-1 (Singapore). Supabase confirmed that their infrastructure in these regions continued functioning normally, and users outside India accessing the exact same Supabase projects had zero issues.
The strongest evidence for this being a DNS-level issue is that when Indian developers switched to Cloudflare DNS (1.1.1.1) or Google DNS (8.8.8.8), connectivity was restored for many users. This strongly suggests that Supabase’s servers were running the entire time, and the ISP DNS resolvers were the primary point of failure.
3. The Government Won’t Tell You Why
The block was issued under Section 69A of India’s Information Technology Act. This section gives the government the power to block public access to any online content if it deems it “necessary or expedient” for reasons including national security, public order, or sovereignty.
Blocking Supabase didn’t just inconvenience developers. It broke production apps serving real users, people ordering food, checking bank balances, logging into SaaS products, who had never heard of Supabase in their lives and had absolutely no way of understanding why their apps suddenly stopped working.
That’s a meaningful distinction, and one that I think the regulatory framework hasn’t caught up with. There’s a difference between blocking a website and breaking infrastructure that other websites quietly run on.
4. The Scale of the Damage
Let me put the scale of this in perspective.
In January 2026, just one month before the block, Supabase saw roughly 365,000 visits from India, representing 179% year-over-year growth. India had become Supabase’s fourth-largest traffic source globally, accounting for about 9% of its global visits.
And India’s developer community is only growing. As of October 2025, India had over 21.9 million developers on GitHub, the world’s second-largest developer community after the United States, and it’s projected to surpass the US later this decade.
Developers reported a range of apps being affected, from payment-related platforms and SaaS products with Indian user bases to student projects and startup MVPs.
No specific company names were publicly reported, likely because admitting “my app runs on Supabase” while it was being blocked by the government isn’t great PR for a startup trying to raise its next round.
Revenue was likely affected → Any app monetizing through subscriptions, transactions, or ad impressions in India would have been losing money every hour the block persisted.
For bootstrapped startups operating on thin margins, 8 days of downtime in a market representing 9% of traffic is hard to absorb, though no startup publicly disclosed financial impact.
Developer confidence was shaken → The risk that a government might silently block your backend provider is not something that shows up in anyone’s architecture review, and after this incident, a lot of developers in India are going to think twice before betting their stack on any single hosted provider.
The mood on r/developersIndia during the block was a community in disbelief, torn between figuring out workarounds and just being genuinely angry. Some pushed for immediate migration to alternatives like Neon, others pointed out the irony of India aspiring to be a global tech hub while simultaneously blocking the tools its developers depend on.
5. Supabase’s Response and What It Revealed
Supabase’s status page updates over the 8 days paint a really interesting picture. If you read them in order, you can watch the language shift from technical DNS troubleshooting to quiet government diplomacy:
Day 1 (Feb 24): Supabase called it a DNS resolution issue affecting customers having difficulty connecting from AP-south-1 locations. They pointed to ISP DNS availability and suggested switching to Cloudflare or Google DNS. No mention of a government order.
Day 2 (Feb 25): The framing shifted slightly - now it was a service provider in the region not serving correct DNS responses.
Day 3 (Feb 26): They acknowledged other ISPs in India may be impacted and said they had engaged multiple teams communicating with multiple entities in India.
Day 5 (Feb 28): For the first time, they officially said users in India were blocked. The advice stayed the same: use a VPN, switch DNS, or try custom domains.
Day 7 (Mar 2): They said they had made important progress in contact with the relevant authorities.
Day 8 (Mar 3): Decision makers are involved on all sides. That’s the language of government negotiations, not DNS troubleshooting.
Day 9 (Mar 4): Access fully restored. They thanked the Ministry of Electronics and Information Technology (MeitY) for their prompt action.
Notice what happened there? The incident started as a DNS resolution issue and ended with thanking a government ministry for resolving it. At no point did Supabase’s official communications use the phrase government block. This was diplomatically smart since you don’t antagonize the government you’re negotiating with, but it left developers completely in the dark about the real cause for days.
On X, in one of their updates, they described it as a service provider not delivering correct DNS responses and told customers to switch to an alternative DNS provider or use a VPN in the meantime.
To put it mildly, the developer community was not impressed, and for good reason.
Telling someone to use a VPN is advice that works for an individual developer who wants to access a blocked website. It is emphatically not advice that works for someone running a production app serving thousands of end users.
You cannot ask your users to install a VPN to use your food delivery app. That’s not how real-world software works, and Supabase should know that better than anyone.
As one developer put it on Reddit, the suggested fixes of VPN or DNS changes are “completely unviable for production apps with real users” - and that frustration echoed across every forum I read.
I do want to be fair here, Supabase was dealing with something outside their control, and there’s no playbook for when your provider gets banned by a government. But when you’re the infrastructure layer for one of your top four markets globally, the bar for crisis communication is higher than just telling people to try a VPN.
What would have been more helpful is immediately flagging custom domains as the production-grade workaround, offering temporary free access to custom domain features for affected users on the free tier, and being upfront about the government block rather than slowly evolving the language over 8 days.
6. The Workarounds (And What Actually Worked)
The developer community rallied and explored a range of approaches. Here’s an breakdown of what worked and what didn’t:
Changing DNS (1.1.1.1 or 8.8.8.8) → Worked for individual developers sitting at a terminal. The ISP was blocking at the DNS level, so pointing to a different resolver could bypass it. But your end users aren’t going to change their DNS settings. This fixes your development environment, not your product.
Using a VPN → Routing your traffic through a VPN bypassed the block entirely, but telling your end users to install a VPN just to use your app isn’t a serious production workaround.
Supabase Custom Domains → This was probably the most practical production fix. If you were on a paid Supabase plan, you could configure a custom domain (like api.yourdomain.com) for your project.
Since ISPs were specifically blocking *.supabase.co, a custom domain wouldn’t be affected. The catch? Custom domains are a paid add-on at roughly $10/month per domain, available only on paid plans. Most developers on the free tier, and there are a lot of them in India, didn’t have this option when they needed it most. Supabase could have temporarily unlocked this feature for affected free-tier users.
Reverse Proxy via Cloudflare Workers → This turned out to be the most robust community-driven solution, and honestly, it’s my favourite part of this whole story. The thing I love most about the tech community is that when things break, people don’t just complain - they build. And that’s exactly what happened here.
Developers set up Cloudflare Workers on their own domains that proxied requests to Supabase. To the ISP, the app appeared to be talking to the developer’s own domain rather than to Supabase. Here’s what the architecture looked like:
And then someone from community went a step further. Sunith VS, an indie developer from India whose own production app broke when the block hit, spent a weekend building JioBase - a free, open-source managed reverse proxy that any developer could use by simply swapping one URL in their code. No paid plan required, no infrastructure to manage, just change yourproject.supabase.co to yourproject.jiobase.com and your app worked again.
What makes this story special is that Sunith didn’t just build it and walk away. He funded the entire Cloudflare infrastructure out of his own pocket, proxying millions of requests for free across India. No VC funding, no ads, no monetization. Just one developer who decided that Indian devs deserved a real fix, not a paywall. The community rallied around it, and honestly, the name JioBase alone tells you everything you need to know about the situation.
Now that the block has been resolved, JioBase has stopped its managed service and advised developers to migrate back to their original Supabase URLs. But the project lives on as open source - you can self-host your own reverse proxy with a single command (npx create-jiobase) if you ever need it again. That’s the beauty of open source: “the fix doesn’t disappear when the crisis does.”
That said, the community was right to flag the security implications. Not everyone was comfortable routing their Supabase traffic through third-party proxies, and they shouldn’t have been.
As one developer on Reddit cautioned, a proxy is “just a console.log() away of headers & http body flushing everything onto logs” - a fair warning for anyone blindly trusting community workarounds with their production traffic.
The safer approach, as several developers pointed out, was to self-host the proxy yourself rather than relying on someone else’s infrastructure. It’s a reminder that urgency and security don’t always pull in the same direction.
Relocating Servers Outside India → If your backend was hosted in India and made calls to Supabase, moving it to a region like Singapore sidestepped the block entirely. The latency trade-off wasn’t ideal, but it was better than being completely offline.
7. It’s Unblocked Now.
Supabase engaged directly with India’s Ministry of Electronics and Information Technology (MeitY) to resolve the situation. On March 4, 2026, about 8 days after the block was first reported, they announced that access had been fully restored for users across India. For anyone still experiencing issues, they advised clearing DNS cache and allowing up to 24 hours for ISP-side changes to propagate.
8. What This Should Change About How You Build
I think this incident is a wake-up call for a category of risk that most of us simply don’t factor into our architecture decisions. Here’s my take:
Vendor lock-in now includes geopolitical risk → When we evaluate a platform, we think about pricing, features, maybe data portability. We don’t think about what happens if this provider gets blocked in our market. After the Supabase incident, it belongs on the checklist, especially if you serve users in countries where government intervention in internet infrastructure is not uncommon.
Custom domains should be a default, not an upgrade → If you’re running a production app on any BaaS, having your own domain in front of it isn’t about branding. It’s a resilience measure. If your provider’s domain gets blocked, rate-limited, or flagged, your custom domain keeps you running. This should be standard practice for any production deployment, not something you discover you need during an emergency.
Monitor your DNS health, not just your server health → Most monitoring setups check whether your server is responding but don’t track DNS resolution from multiple geographic locations. After this incident, tracking API latency, login failures, and DNS resolution health from within your key user markets should be part of your observability stack.
Automate the things you can control → You can’t predict when a government will block your backend provider. You can’t control ISP-level DNS decisions. But you can make sure the code you’re shipping is rock solid before it ever touches production.
When your app does come back online after an incident like this, the last thing you want is to discover it’s also riddled with bugs you could have caught earlier. Tools like CodeRabbit can automatically review every pull request for security vulnerabilities, code quality issues, and logic errors before they’re merged, cutting down review cycles and catching the kinds of problems that compound during a crisis.
Open source is insurance you hope to never use → One of Supabase’s biggest differentiators is that it’s fully open source. If the situation had escalated or the block had become permanent, developers could, in theory, self-host the entire Supabase stack on their own infrastructure. That’s a meaningful safety net, and it’s exactly the kind of insurance that proprietary platforms like Firebase simply cannot offer.
You may never need to self-host, but knowing you can changes the risk equation entirely. This incident is probably the strongest real-world argument for choosing open-source infrastructure I’ve seen in years.
Have a reverse proxy ready to go → The Cloudflare Workers proxy approach was the most effective production workaround during this incident. Setting up a reverse proxy on your own domain before an emergency hits means you can flip a switch instead of scrambling. It takes an afternoon to configure and could save your product when nothing else will.
Every BaaS provider should have an incident playbook for this → This is new territory for infrastructure providers. Having a clear, pre-built response for when your service gets blocked by a government should be part of every BaaS provider’s incident response plan going forward, not something they improvise in real-time while suggesting people use a VPN.
The blocking mechanism needs more transparency → I understand that governments have legitimate security concerns. But blocking developer infrastructure that powers production applications, without any public explanation, and with a legal framework that actively prohibits the reason from being disclosed, is a problem. Developers and businesses deserve to know the rules of the game they’re operating in. You can’t plan for risks you’re not allowed to know about.
That’s a wrap for this edition.
I’d genuinely love to hear how this impacted you or your team, especially if you had a Supabase powered product in production when the block happened. Did you have a contingency plan? Did you consider migrating? What did you tell your users?
Feel free to share your perspective. I think this is a conversation worth having.
Thanks so much for taking a few minutes to read.
If you liked the post, consider sharing with a friend or community that may enjoy it too.