Static site or Django? A cost comparison for a personal blog

When setting up a personal blog, the first question is usually “which technology”, but the better question is “what will this blog cost me over months and years”. Cost is not only the monthly bill: keeping a server running, updated and backed up is a cost too. This post compares three routes on that measure: a static site with Astro, a classic Django site running on a server, and a hybrid that combines the two. Prices were read from the companies’ official pages on 14 November 2026 and may have changed since. Where a price could not be reached or the page does not state one, that is said openly below instead of being invented.

Route A: Markdown files, a static build, Cloudflare

Here the posts are Markdown files in a git repository. The build renders every page to HTML in advance and the output folder is uploaded to a CDN. There is no running application, no database and no operating system to look after; the visitor receives a ready-made file.

Hosting cost follows from that and is very low. Cloudflare’s Workers pricing page says that requests to static assets are free and unlimited. According to the same page the free plan has a limit of 100,000 Worker requests per day, but it applies to requests that run dynamic code, so a static site does not run into it. The paid plan has a minimum charge of 5 USD per month, which a purely static blog has no reason to need. Cloudflare Pages’ free plan gives 500 builds per month, 20,000 files per site and 25 MiB per file, generous ceilings for a blog.

The one remaining permanent cost is the domain name. Cloudflare Registrar’s page states that it sells domains at cost, without markup, but it does not list a .com price. So no figure is given here; the exact amount has to be read from the domain search in the dashboard. In short, the recurring cost of the static route comes down to the domain renewal.

The price on the effort side is real: page types, design, search, RSS and a sitemap have to be built once. But that is setup work; after it, there is no server to update. Even search does not need one: Pagefind scans the output after the build and produces a static index, and according to its docs it builds a separate index for each language.

Route B: Django on a server

Django’s strongest point is the admin: define the models and the panel comes ready-made. But for that panel to run, you need a server, a database and an always-on process, and that is where the price question begins.

Most free options are unsuited to publishing your own site on your own domain. According to PythonAnywhere’s pricing page, the free Beginner account does not support custom domains; its single app runs at username.pythonanywhere.com. The Developer plan, which is needed for a custom domain, costs 10 USD per month. On Render’s free tier a web service spins down after 15 minutes without traffic and takes about a minute to start again, during which visitors see a loading page. The same document says free services have no persistent disk and that the local filesystem is reset on redeploy, restart or spin-down; the free Postgres database expires 30 days after creation, followed by a 14-day grace period. For a Django blog running on a plain SQLite file, that means losing data.

For a lasting setup, renting your own virtual server remains. On Hetzner Cloud’s page the cheapest option (Regular Performance) starts at 5.49 euros per month excluding VAT. That price is for the server itself; the domain, operating system updates, the TLS certificate, backups and security patches are separately your responsibility. That extra load is measured in time rather than money, and there is no source here that measures it; but it is clearly not zero.

Multilingual support, search, a sitemap and RSS are also either added through ready-made apps or built by hand in Django. All of it is possible and none of it comes ready. Unless a cache or a CDN is added, pages generated on the server do not reach the speed of static files by themselves.

Route C: the Django admin with a static build

The third option promises the best of both worlds: content is entered in the Django admin, an export step turns it into files, Astro builds a static site from those files and the output goes to Cloudflare. On paper it is attractive: a familiar panel and a fast, cheap site.

But the panel has to run somewhere. The server it needs is Route B’s server, so you carry Route B’s cost and maintenance load. On top come an export command, a build trigger and the work of keeping the two in step. If the panel is used only a few times a week, paying for a server that is up around the clock is out of proportion. Running the panel only on your own computer and pushing the output to git brings the cost to zero, but then there is a second tool that lives only on your machine.

The real question for this route is whether the comfort of the Django panel is worth the cost of a separate server and the added complexity. Given that a git-based CMS does most of the same job on plain files, the answer is usually no.

Comparison and decision

	A: Static site	B: Django	C: Hybrid
Recurring hosting cost	Free for static requests (Cloudflare)	At least 5.49 euros + VAT (Hetzner)	Same as B
Setup effort	Medium (page types, design)	High (site, search, multilingual, caching)	Highest
Maintenance	No running server	OS, TLS, backups, patches	Same as B, plus the export
Where the data lives	Files in git	In a database	In a database, copy in files

The decision depends on what the blog is. A personal blog that is mostly written content and collects no user logins or form data needs nothing that requires a server. For such a blog the static route brings the recurring cost down to the domain and removes most of the maintenance burden. Django earns its place in applications where users enter data, accounts exist and queries are dynamic; a blog rarely needs that on its own.

This comparison has a limit as well: the numbers cover infrastructure prices only. The hourly value of your own labour, your experience, and the fact that you may already know Django can change the equation. But since the same job can be published without opening a server at all, choosing a server calls for a concrete reason.