How DevQuake is hosted

This post contains a referral link to Hostinger. If you sign up through it we may earn a commission, at no extra cost to you. We pay for our own hosting, and everything below is what actually happened to us.

People who build small sites often ask what running something like DevQuake really takes. Here is our setup, including the part that went wrong.

What runs where

DevQuake is one Next.js application with independent apps, each on its own subdomain: darts.devquake.com, utilities.devquake.com and so on. It runs on a managed Node.js plan at Hostinger, with MySQL databases on the same plan.

The website and every app subdomain run their own copy of the application. That one fact shapes almost every other decision here, as you will see.

Deploying is simple: merging to the main branch starts a build, which publishes a ready-to-run bundle, and the host redeploys it. Nothing is built on the server.

What to check on price

The blog's ads and referrals help pay for the hosting, so that the apps themselves can stay free of ads.

Hosting is not the only bill. The domain, and the text-to-speech service behind the workout coach's natural voices, are separate. Check the current price before you decide, because hosting plans are often much cheaper in the first term than on renewal.

The day we ran out of resources

On 22 October 2026 our plan ran out of resources. Pages started answering with the host's own 503 error page, or simply hung.

The cause was threads. A plan like ours limits the processes and threads you may run, 120 in our case. Each copy of the application needed about seven threads, and with more than a dozen copies we were close to the limit before a single visitor arrived.

What we changed

• Idle copies now exit. An app subdomain nobody is using shuts down and starts again on the next visit. A rarely used app costs almost nothing, at the price of a slower first page.
• Fewer threads per copy. Node.js can run with smaller thread pools than it uses by default, and ours is now limited.
• No always-on jobs. Scheduled work runs in one shared scheduled run, not in timers inside each process.
• Heavy work happens in the browser. Reading a meter photo or shrinking a picture runs on the visitor's device, not on our server.
• Files go in the database. A redeploy replaces the application folder, so anything saved on disk would be lost.
• Every new feature gets a cost check: threads, memory, jobs and storage.

Who this setup suits

It works well if you run one site or a few small apps, your traffic is modest, you want one panel for domains, SSL, databases and email, and you do not want to look after a server.

It does not suit you if you need long-running background workers, native modules that start their own threads, or many separate always-on processes. You will hit the process limit, and you would be better off with a VPS.

What we would tell ourselves

1. Find the process limit before you add the tenth app. Look at the resource page in the panel, not only at disk space.
2. Count threads, not just memory.
3. Put in idle shutdown from the start.
4. Get the SSL certificate for a new subdomain before you open it, especially if your site sends HSTS with subdomains included: browsers refuse the site without one.

If you want to try it

If this setup fits what you are building, you can sign up through our referral link: see Hostinger's plans. It costs you nothing extra and helps pay for DevQuake. If it does not fit, a small VPS is the honest alternative.

Read how DevQuake works