2048

Last reviewed Aug 26, 2026 · 675 words

The whole deployment of 2048 is a git clone and a web server; there is no step three. Gabriele Cirulli's original sliding-tile puzzle from 2014 is plain HTML, CSS and JavaScript with no backend, no database and no build, which makes it the single best "hello world" for a self-hosted setup. If you have never put a reverse proxy in front of anything, put it in front of this first, because when something breaks you will know the game was not the problem.

From clone to playing in about ninety seconds

git clone https://github.com/gabrielecirulli/2048.git /srv/2048
cd /srv/2048
python3 -m http.server 8080

Open http://your-host:8080 and play. That Python one-liner is fine for a test and wrong for anything permanent, so the real version is a proper static server. With Caddy it is a two-line site block:

2048.example.com {
    root * /srv/2048
    file_server
}

Caddy fetches a certificate on the first request. Any other static server works identically because there is nothing to configure: the repository's index.html references its stylesheet and scripts by relative path, so it serves correctly from a subdomain, a subpath, or a file URL on your desktop.

The 64 MB in the catalogue is the web server, not the game

The game runs entirely in the visitor's browser. Your server's only job is to hand over a few hundred kilobytes of files once, after which the machine could go to sleep and the tab would keep working. The catalogue's 64 MB minimum is what a small nginx or Caddy process needs, and even that is shared with every other static site the same server hosts. This is the property that makes static apps so pleasant to run: no process to crash, nothing to update on a schedule, no memory that grows overnight.

Scores are stored with the browser's localStorage, scoped to the page's origin. Two consequences follow. Each visitor keeps their own best score and nobody else can see it, which is why the catalogue lists it as single-player only. And if you move the game from one hostname to another, everyone's best score resets, because the browser treats the new origin as a different site.

What hosting it teaches

Every static web app you will ever self-host follows this pattern: files on disk, a server that reads them, TLS in front. The password-manager front end KeeWeb, dashboards like Homepage, and the output of every static site generator are the same shape with more files. Getting 2048 working end to end, with a real hostname and a real certificate, means you have solved the general problem once. It is also the least stressful place to learn subpath hosting: a handle_path /2048/ block in Caddy with root /srv/2048 puts the game under an existing site, and the relative asset paths mean it just works.

Limits and where to go next

"Minimal features" is a fair summary. There are no accounts, no leaderboard, no multiplayer and no settings beyond the board itself, and the upstream repository has been essentially finished for years, which is exactly what you want from something you will never have to maintain. Forks add larger boards, themes and undo; the games category has plenty of browser titles built the same way once you want more than one. For a family or a small office a self-hosted copy also has a quiet advantage over the public site: no advertising, no analytics, and it works on a LAN with no internet at all.

What I'd do

Clone it into /srv/2048, serve it with Caddy on its own subdomain, and use it as the canary for your reverse proxy setup. Then leave it alone. A game that has needed zero maintenance in a decade is a rare thing on a homelab, and the fact that it is also a good game is a bonus.