DDoS protection for small apps in India: what it changes

Most small apps never see a real denial-of-service (DoS) attack. The ones that do usually find out the hard way: the site is slow, then it is down, and the hosting bill or the inbox fills up with complaints before anyone works out that the traffic is not real.

On 1 October we turned on DDoS protection for every service on Voroa. This post is what we learned doing it - what the protection actually does, what it changes for an app, and the trade-offs we chose to accept.

Two layers, and why you need both

There are two very different kinds of defence against unwanted traffic.

Network-level protection sits in front of everything. A large flood - millions of requests from thousands of machines - has to be dropped before it reaches any one server, because no single server can absorb it. This is the job of an edge network: a large set of machines spread across many locations that receives your traffic first and only passes on what looks real.

Application-level defence is your own code refusing to do expensive work for a client that is asking too often. This handles the far more common case: one script in a loop, one scraper, one misconfigured client hammering a login endpoint.

You need both. The edge stops what your server could never survive; rate limiting stops what the edge would reasonably let through because it looks like an ordinary visitor.

What changed on Voroa

Every service’s Voroa address now goes through an edge network by default. Our own proxy still limits each visitor’s request rate, so one noisy client cannot take a service down for everyone else.

Customers on a paid plan can now put their own custom domains behind the same protection. That takes one DNS change: the domain’s record points at our edge address instead of directly at the service. We prepare the domain first and issue its certificate before the switch wherever we can, so the site keeps working while the record moves.

The trade-offs we accepted

Putting an edge in front of an app is not free. These are the changes an app sees, and the settings page shows them next to the switch:

• The edge refuses uploads over 100 MB. Send large files straight to a storage service.
• The edge times out a request that takes more than 100 seconds to start answering. For long work, answer first with a job id and carry on in the background.
• WebSockets work, but the edge can close an idle connection. Most client libraries already reconnect.
• The visitor’s address moves. It is the second-to-last entry of X-Forwarded-For, because the last one is the edge server that connected to your service.

Each service has its own switch. If one of these does not suit an app, its owner can turn the protection off for that service alone.

What we did not do

We did not turn on automated bot blocking. On our own platform it blocked the payment provider’s webhooks: payments went through but our side never heard about them. For a platform that bills customers, that failure is worse than the traffic it stops, so it stays off.

We also kept customer data where it was. We store it on servers in India; the edge network only carries requests on their way to the service.

If you run your own servers

A few things carry over to any small team:

1. Rate-limit the expensive endpoints first - login, signup, search, anything that sends email. That is where a single bad client hurts most.
2. Know your edge’s limits before you need them. Upload size and request timeouts are the two that break real apps.
3. Test the rollback. On 1 October we switched the protection off and on again in production, and visitors saw no errors while it came back. A switch you have never flipped back is not a switch.

Voroa customers can read the full details in the DDoS protection guide, and see every protection we run on the security overview.