iercan's dev blog

homelab 101

Tue, 06 Oct 2026 00:00:00 GMT

I’ve been messing with servers for a while: random VPSes for my own projects, and more and more cloud deployments at work. It went step by step: plain Linux and nginx, then Docker (mostly on hetzner), then cloud providers like AWS, Azure. Turns out I kinda like that type of work, why not have a little setup at home to play with

the hardware

Many years ago I wanted to buy Raspberry Pis, but nowadays they’re way too expensive… still good pieces of hardware though.

4 GB of memory for €120 (without delivery).

So I bought 2 “mini PCs” instead (I think the M700 isn’t really a mini PC?):

	Intel NUC 8	Lenovo ThinkCentre M700 Tiny
Price	€107	€133
CPU	i5-8365U	i5-6500T
RAM	16 GB DDR4	32 GB DDR4
Storage	120 GB SATA SSD	512 GB SATA SSD

I didn’t plan on buying 2 pieces of hardware, but when I saw the amount of DDR4 RAM the M700 comes with, it was insane value

so here they are:

The CPU of the NUC 8 is better. One mistake: I thought the CPU would be very important for a homelab (Proxmox), but usually your stuff runs at a low % CPU when idle. What’s more important is the RAM (how many VMs and containers you can run) and the storage.

opening them up

opening the NUC 8:

I thought it was an NVMe drive at first but nop, it’s just the form factor. it’s SATA

opening the M700:

a 512 GB SATA SSD (I’ll add it to the NUC 8), and under there is the RAM!

RAM swap. I’ll only use the NUC 8 for now since it has the better CPU:

out: 2× 8 GB Crucial. in: 2× 16 GB Corsair Vengeance.

very loud fan

First thing to test was flashing the latest Ubuntu on the NUC 8… and it felt like I got the loudest PC ever. This is very common on the NUC 8 apparently. There are 2 problems:

the fan is low quality (here’s a short about it)
the BIOS is faulty and the fan control doesn’t work, so it should be updated to the latest version. common problem (reddit thread), you just need to update the BIOS.

So I had to do both: replace the fan, and update the BIOS.

mine is the NUC8i5BEH (Intel NUC gen 8, i5).

and now everything is ok. good temperatures too!

proxmox

let’s learn Proxmox! :)

everything works:

btw to avoid the no subscription pop-up and be able to “apt update” you can paste a community script.

bash -c "$(curl -fsSL https://raw.githubusercontent.com/community-scripts/ProxmoxVE/main/tools/pve/post-pve-install.sh)"

next up: I wanna test the Proxmox Terraform provider, learn more about k8s on real hardware, try out random software, and maybe self-host an RSS reader…

should you put Tailscale everywhere?

Tue, 29 Sep 2026 00:00:00 GMT

A while back I found a hidden link on Google for a limited sale: a VPS in the US for $2/month. I bought it pretty much immediately, which is how I ended up owning 4 VPSes: 3 “proper” Hetzner ones in the EU and this “shady” one.

$2 is quite cheap, especially considering what AI is doing to hardware prices, and the catch is that the host “oversubscribes” its CPUs. My 3 vCPUs are shared with other people, so a noisy neighbour can steal my CPU time. It’s common enough that top has a column for it: st, “time stolen from this vm by the hypervisor”¹.

It runs an old project of mine, notstrike (a multiplayer Counter-Strike game engine and WebSocket server), which is basically just a Caddy reverse proxy for SSL and a few Docker containers for the game servers:

CONTAINER ID   IMAGE                    COMMAND                  CREATED         STATUS                  PORTS                                                                                             NAMES
5820602e249c   us-game-server-1         "docker-entrypoint.s…"   12 months ago   Up 9 months             4011/tcp                                                                                          notstrike-server-eu-1
3214c954edc6   us-game-server-2         "docker-entrypoint.s…"   12 months ago   Up 9 months             4011/tcp                                                                                          notstrike-server-eu-2
9830c7ce706f   louislam/uptime-kuma:1   "/usr/bin/dumb-init …"   12 months ago   Up 9 months (healthy)   0.0.0.0:3001->3001/tcp, [::]:3001->3001/tcp                                                       uptime-kuma
e61f5e8016fe   caddy:2-alpine           "caddy run --config …"   13 months ago   Up 9 months             0.0.0.0:80->80/tcp, [::]:80->80/tcp, 0.0.0.0:443->443/tcp, [::]:443->443/tcp, 443/udp, 2019/tcp   notstrike-caddy-eu

Here’s the US server browser:

Honestly, it’s never given me any trouble. I just wouldn’t trust it with anything sensitive (the price is kind of the reason why).

securing a VPS

I’ve had VPSes for 6 years now:

classical ways of securing your vps:

disabling root password authentication
moving SSH off port 22
installing fail2ban
putting a firewall in front of it, at the Hetzner level
not exposing databases (under Docker) on 0.0.0.0
not running things as root

the new way

But the new way I do it (and many people do!) is Tailscale.

Tailscale puts all your devices on one private network (a “tailnet”) and lets them talk to each other directly over encrypted WireGuard connections, even through NAT and firewalls, without forwarding a single port. There’s still a central “coordination server”, but it’s basically a shared drop box for public keys, and the private keys never leave the device that generated them.

So I can close every port except 80 and 443, leave the firewall at the Hetzner level and drop SSH exposure completely. And on my own computer, tailscale status gives me a line for every device on my account with its Tailscale IP, name, owner and OS.

Diagram: The internet reaches Caddy on ports 80 and 443. Ports 22 and 3001 are blocked from the internet and only reachable from my laptop over Tailscale. See it in the post.

the danger

I was putting Tailscale on the shady VPS and thought, maybe I should actually check how this works before connecting it to all my stuff

Can the VPS SSH into my laptop? Into my other machines? if someone gets into this VPS, can they get into my other machines too? (or maybe I’m dumb, idk)

Tailscale’s docs even have a warning about it:

Although access control policies in Tailscale follow a deny-by-default security model, the default access control policy is to allow all devices within a tailnet to connect to each other.

Tailscale docs, “What devices can connect to or know mine?”²

here’s what Tailscale allows by default:

{
  "grants": [
    {
      "src": ["*"],
      "dst": ["*"],
      "ip": ["*"]
    }
  ]
}

The * source “lets any device or user start connections”, to any device, with any protocol on any port³.

So yes: with the default policy, the shady VPS can open a connection to any port on my laptop and on my other VPSes. A dev server on 0.0.0.0 or a database without a password would just answer 🥲

Diagram: With the default policy, the shady VPS can connect to every other device: my laptop, my two computers and my three Hetzner VPSes. See it in the post.

And SSH? A regular SSH server still asks for a key or a password. But on my VPSes I use Tailscale SSH (I just type tailscale ssh), and there’s no key or password there. Its server “already knows who the remote party is”, so it uses the SSH authentication type none, and the ssh rules in the policy decide who gets in⁴.

And if the VPS is logged in with my account, for Tailscale it’s one of my devices:

it sees every other device I own, even the ones the policy doesn’t let it connect to²
Taildrop (if it’s turned on) can send files between it and my devices, “even if access control policies are used to restrict access to the devices”⁵ (on macOS, they land in ~/Downloads)

my policy

I found tags while reading the docs. I hadn’t heard of them before, but they let me give the VPS different permissions from my laptop. Here’s the policy I ended up with:

{
  // who can tag (only admins so just me)
  "tagOwners": {
    "tag:untrusted": ["autogroup:admin"],
  },

  "grants": [
    // autogroup:member = devices logged in as a person. A tagged device isn't one, so this grant skips it.
    { "src": ["autogroup:member"], "dst": ["*"], "ip": ["*"] },
  ],

  "ssh": [
    // "check" = log in again in the browser before SSH, then you're good for 12 hours.
    {
      "action": "check",
      "src": ["autogroup:member"],
      "dst": ["autogroup:self"],
      "users": ["autogroup:nonroot", "root"],
    },
    // "accept" = straight in, Tailscale already knows it's me.
    {
      "action": "accept",
      "src": ["autogroup:member"],
      "dst": ["tag:untrusted"],
      "users": ["autogroup:nonroot", "root"],
    },
  ],
}

And then every VPS got the tag. Even the “proper” Hetzner ones: I trust them more, but they still have no reason to reach my laptop.

the tag

"tagOwners": {
  "tag:untrusted": ["autogroup:admin"],
},

When I logged in to Tailscale on the VPS, it got added to my account, like my laptop. So it counted as one of my devices, and could reach everything my laptop can, including my laptop.

Tagging it takes it off my account.

tagOwners says who’s allowed to put tag:untrusted on a device. Only admins, so only me.

the grant

"grants": [
  { "src": ["autogroup:member"], "dst": ["*"], "ip": ["*"] },
],

Grants are just allow rules: who can connect to what. There’s no “deny” rule, everything starts out blocked, so “the only possible action is accept”⁶. To block something, you just leave it out.

My one grant only lists my devices as the source, and the VPS isn’t one of them anymore. So it’s left out, and that’s the block. My laptop can still reach it (and the VPS can reply), the VPS just can’t start anything.

Diagram: With the tag, my laptop can connect to both VPSes, but the VPSes can't connect to my laptop or to each other. See it in the post.

Even if someone hacks the VPS and tells Tailscale to ignore the rules, it doesn’t help them: my laptop checks incoming traffic itself.

the SSH rules

"ssh": [
  {
    "action": "check",
    "src": ["autogroup:member"],
    "dst": ["autogroup:self"],
    "users": ["autogroup:nonroot", "root"],
  },
  {
    "action": "accept",
    "src": ["autogroup:member"],
    "dst": ["tag:untrusted"],
    "users": ["autogroup:nonroot", "root"],
  },
],

The first rule is Tailscale’s default, and it’s mostly there for the “someone stole my laptop” case: SSH into my other devices needs a fresh browser login every 12 hours, so a thief gets cut off from SSH pretty fast (not from the other ports though, that’s what the grant is for).

The second rule is pure convenience: from my laptop, I SSH into my VPSes without any key, password or browser, because Tailscale already knows it’s me.

on the vps no rule lets it SSH anywhere, so it can’t.

the test

ok enough talk does it work?

I SSHed into the VPS (tailscale ssh ncr@shady-vps) and tried to reach my MacBook from there. First, tailscale ping:

$ tailscale ping --c 3 --timeout 3s macbook-pro-de-ercan
pong from macbook-pro-de-ercan (100.72.247.81) via [my home IPv6]:41641 in 26ms

It finds it, which confused me for a second. Turns out tailscale ping only checks whether the two Tailscale clients can find each other, it doesn’t send any real traffic. With --icmp it sends a normal ping through the tunnel, and this time my Mac drops it:

$ tailscale ping --icmp --c 3 --timeout 3s macbook-pro-de-ercan
ping "100.72.247.81" timed out
ping "100.72.247.81" timed out
ping "100.72.247.81" timed out
no reply

SSH times out too:

$ timeout 20 ssh -o BatchMode=yes -o ConnectTimeout=5 iercan@macbook-pro-de-ercan true
ssh: connect to host macbook-pro-de-ercan port 22: Connection timed out

And tailscale ssh iercan@macbook-pro-de-ercan just hangs until timeout kills it, 20 seconds later.

(Nothing listens on port 22 on my Mac anyway. From the Mac itself it says “Connection refused”, but from the VPS it’s “timed out”, because the packets never even reach macOS.)

The other way around works fine. From my Mac:

$ tailscale ping --icmp --c 3 --timeout 3s shady-vps
pong from shady-vps (100.124.31.123) via ICMP in 31ms

what’s left

risk 1: it still sees my devices

If I run tailscale status on the VPS, I can still see my laptop and my other computers. They’re allowed to connect to it, so it knows about them²:

$ tailscale status
100.124.31.123  shady-vps             shady-vps.<tailnet>.ts.net  linux  -
100.72.247.81   macbook-pro-de-ercan  me@                         macOS  active; direct [my home IPv6]:41641, tx 66272 rx 62936
100.82.19.89    ncr-z490m             me@                         linux  offline, last seen 1h ago
100.76.7.249    pop-os                me@                         linux  offline, last seen 1h ago

If that bothers you, only let the devices that need the VPS connect to it.

But a VPS can’t see other VPSes! My other VPSes are tagged too, and no grant lets a tagged device connect to another one, so they don’t know about each other².

risk 2: my own connections

The VPS can’t start connections, but my browser can, and my laptop can reach everything.

With a trick called DNS rebinding, any website I open can point its own domain at one of my tailnet IPs, and the browser then lets its JavaScript talk to that device as if it were the same site. That’s not specific to the VPS, but the VPS makes it easier: I actually open pages it serves, and it already knows my tailnet IPs (risk 1).

Tailscale’s best practices mention this one: “a Tailscale node visiting a malicious web page can be triggered to run a client-side script and attack other nodes in the tailnet”⁷.

risk 3: my Tailscale account

Whoever gets into my Tailscale account can rewrite the policy, remove the tag or add devices. Tailscale recommends MFA on your login, “ideally using a hardware token”⁷.

And if you don’t trust Tailscale itself: with Tailnet Lock, a new device needs a signature from one of your devices, so Tailscale can’t add one behind your back⁸. The policy still comes from Tailscale’s servers, though⁹.

risk 4: my own devices

if someone gets into my laptop, they get root on every VPS too. the tag doesn’t help here: I allowed that laptop to SSH into all my VPSes, so whoever’s using it can too.

I could make Tailscale ask for a browser login before SSHing into a VPS. That’s what check does, and Tailscale recommends it for root⁷:

     // SSH into untrusted machines.
     {
-      "action": "accept",
+      "action": "check",
       "src": ["autogroup:member"],
       "dst": ["tag:untrusted"],
       "users": ["autogroup:nonroot", "root"],
     },

With check, SSH asks you to log in again in your browser, and then you’re good for 12 hours. (i mean, if they have access to your computer, they can also just use your browser to accept this, but you get the point.)

that’s all!

So, should you put Tailscale everywhere? I’d say yes, as long as every machine you don’t trust gets a tag, and that tag isn’t allowed to connect to anything.

more details here: What devices can connect to or know mine?

top(1), procps-ng manual. ↩
Tailscale docs, What devices can connect to or know mine? ↩ ↩² ↩³ ↩⁴
Tailscale docs, Grant examples: Allow all ↩
Tailscale docs, Tailscale SSH ↩
Tailscale docs, Taildrop ↩
Tailscale docs, Syntax reference for the tailnet policy file ↩
Tailscale docs, Best practices to secure your tailnet ↩ ↩² ↩³
Tailscale docs, Tailnet Lock ↩
Tailscale blog, How Tailscale works, March 2020. ↩

this blog runs on astro now

Sun, 20 Sep 2026 00:00:00 GMT

I started this blog in January on Hugo, with the PaperMod theme. Really cool tool. But since then I wanted a bit more control, and a few interactive pages under my domain.

what I want:

markdown first, with each post’s images inside the same folder (simple)
static files, no React or Vue (for a blog, even plain HTML could be enough)
one push to deploy, on Cloudflare or anywhere else

so I moved it to Astro.

why Astro?

I value simplicity more and more when it comes to the things I host.

I was using Next.js a lot, and I went down their SSR route. But Vercel (the company behind Next.js) often changes their ways. For example, the App Router replaced getStaticPaths with generateStaticParams and often I get dependabots alerts about random CVEs (boring when you self host under your own vps).

I want something so dumb that I can forget about it and throw it on Cloudflare.

under Astro, posts are markdown files in folders, like in Hugo. i can just edit them with vim & do a git push

Also tbh it was very easy to migrate 😅

markdown all the way

Each post moved from content/posts/ to src/content/blog/. It’s still one folder with an index.md and its images:

content

The homepage is an .astro file. The part between the --- lines runs once, at build time:

---
import Base from "../layouts/Base.astro";
import PostList from "../components/PostList.astro";
import { getPosts } from "../lib/posts";

const posts = await getPosts(); // runs at build time
---

<Base title="iercan">
  <p>writing about computer science, backend, infra, linux, and webgames. it's as boring as it sounds :)</p>
  <PostList posts={posts} />
</Base>

So what comes out is plain HTML. Out of 287 pages, exactly one ships JavaScript: the ThinkPad table, for its search and sorting

Everything else works with JavaScript turned off

adding RSS

RSS lets you follow a blog from an app (an RSS reader) instead of visiting the site. I’ve started using it to follow random blogs.

But a lot of feeds only show a one-line summary. So this blog’s feed (/rss.xml) has the full posts, images included. Astro renders each post to HTML at build time, the same way it renders the pages, starting from its RSS guide.

build and deploy

pnpm run build writes one HTML file per page into dist/:

$ pnpm run build
 generating static routes
22:55:13   ├─ /404.html (+24ms)
22:55:13   ├─ /posts/astro-now/index.html (+5ms)
22:55:13   ├─ /posts/thinkpads/index.html (+25ms)
22:55:14   ├─ /posts/web-roblox/index.html (+8ms)
...
22:55:14 [build] 287 page(s) built in 1.80s

Here’s the homepage it writes:

problem: the first deploy failed

Cloudflare has an Astro preset:

But the first build failed with ERR_PNPM_OUTDATED_LOCKFILE. My pnpm-lock.yaml still listed packages I had removed from package.json, and Cloudflare installs with a frozen lockfile.

The fix was three small changes:

sync pnpm-lock.yaml with package.json
pin Node 22 in a .node-version file
delete a leftover package-lock.json (4,897 lines!)

that’s all!

source astro.build

Every ThinkPad in one table

Sun, 20 Sep 2026 00:00:00 GMT

I’ve been using ThinkPads for a long time… They’ve been the most cost-effective laptops I could find on my local used market.

Here are the ThinkPads I’ve had so far:

X220
T440s
L14 Gen 3
T14 Gen 2

Compared to MacBooks, ThinkPads lose their value pretty quickly. That’s actually great if you’re buying one: every year, you get more for your money on the refurbished market.

But I also know what a rabbit hole it can be to find the model you want. Maybe you want an older one, or a collector’s model, or just whatever has the best specs for your budget.

I would love to be able to browse every ThinkPad in one place, but Lenovo’s website has never really been my thing. Here’s what it looks like when I open it (2026):

so I made a static table instead : iercan.com/thinkpads

Think of it as diskprices.com, but for ThinkPads. Right now it has 235 ThinkPads in it, from 2018 to 2026. Here’s what it looks like:

searching and filtering

You can search by model or CPU, sort by any column, and filter for things like “RAM upgradable”, “Ethernet” or “OLED option”. For example, here’s what you get if you search for “L14”:

every generation side by side

If a line has more than one generation (like the T14 or the L14), it also gets a page with all of its generations side by side, so you can see how one model changed over the years.

The cells that changed since the previous generation are highlighted in pink. For example, the T14’s RAM went soldered on the Gen 3 (AMD), and then came back as 2× SODIMM on Gen 5:

one page per model

And every model gets its own page with all of its specs. Here’s the one for the T14 Gen 2 (AMD) (the T14 Gen 2 is one of the ThinkPads I’ve had!):

you can also ask an LLM

LLMs can browse the web with their tools now. And iercan.com is a fully static site on Cloudflare, so it’s very easy to scrape

you can give a newer model the link and just ask it a question.

Here’s the answer it came back with. The little “iercan” tags are its sources, and they link to the model pages on my site:

I put a “Source” line at the bottom of every model page, with links to Lenovo’s PSREF page and PDF for that model, so LLMs (or you!) can double check everything:

This might not be the best use case, but I think it’s good to know. It works with DeepSeek/other models too.

how does it work?

The specs come from PSREF, which is Lenovo’s “Product Specifications Reference”. It turns out PSREF has a JSON API that anyone can use. No login, no API key!

These are the two endpoints I use:

https://psref.lenovo.com/api/ph/ProductCategoryTree lists every product
https://psref.lenovo.com/api/product/Compare/LoadSpecData?ProductKey=ThinkPad_T14_Gen_5_Intel has all the specs for one model

A note on older models: the API doesn’t include all of the older ThinkPads (like the X220 or the T440p). The oldest ones in the table right now are from 2018, so my old X220 and T440s aren’t here.

problem 1: JSON inside JSON

The first weird thing I ran into: the specs are a string of JSON inside the JSON response. So you parse the JSON, and then you parse the JSON again.

problem 2: the specs are sentences

Once you get to the actual values, they’re sentences written for humans, like “One drive, up to 2TB M.2 2280 SSD”:

A couple more examples:

“Two DDR5 SODIMM slots, dual-channel capable”
“One drive, up to 128GB M.2 2242 SSD or 1TB M.2 2280 SSD”

After fighting with Claude to parse every edge case in this JSON (regexes!), here’s the kind of output I store, as plain JSON:

{
  "key": "ThinkPad_T14_Gen_5_Intel",
  "memory": {
    "maxGb": 64,
    "types": ["DDR5-5600"],
    "kind": "sodimm",
    "slots": 2
  },
  "storage": {
    "slots": 1,
    "formFactors": ["2280"],
    "pcie": ["4.0"],
    "maxTb": 2
  },
  "batteryWh": [39.3, 52.5],
  "weightKg": 1.31
}

If you want that data for every model in one file, it’s at /thinkpads.json.

that’s all!

iercan.com/thinkpads

Hopefully it’s useful to people other than me :)

(btw, the L14 Gen 3 is the best one)

Building a multiplayer Roblox-like engine in the browser

Tue, 06 Jan 2026 00:00:00 GMT

DRAFT POST NOT FINISHED.

I’ve been making web games for a while now. My first ones were around 2017, following YouTube tutorials by Daniel Shiffman, which introduced me to p5.js a JavaScript library that makes it easy to create graphics and interactive content in the browser.

Some of my old p5.js projects from 2017-2018

TCP or UDP?

One of the first things you learn when making websites are REST APIs. The client sends a request, the server responds with data. You could use this for multiplayer games, but it’s not ideal.

Older web games used HTTP long polling. The client asks for data, the server waits until it has some, answers, and the client asks again. Slow, but it was the only option since Internet Explorer had no WebSockets.

Libraries like Socket.io abstracted the transport layer, using WebSockets when available and falling back to long polling otherwise.

WebSockets give you a persistent, real-time connection between client and server. They’re TCP-based, so packets are guaranteed to arrive in order. That sounds great but it’s not perfect for fast-paced games.

If a packet is lost, every subsequent packet gets delayed until the lost one is retransmitted and acknowledged. This is called head-of-line blocking, and packet loss happens all the time on real networks, leading to spikes in latency and jitter.

ℹ️ You can simulate packet drop with tools like clumsy on Windows to see exactly how badly TCP can behave in a game context.

UDP is the standard for multiplayer games. It’s faster than TCP because it skips all the reliability overhead (no ACKs, no retransmits), but it isn’t natively available in browsers. You’d have to use WebRTC DataChannels, which are more complex to set up.

Scaling WebSocket game servers

Scaling WebSocket game servers is genuinely hard. Connections are stateful and persistent, which complicates everything. You need to:

Spin up new servers on demand
Route connections correctly through a load balancer
Run a room manager or master server to track which players are in which rooms

Geographical latency matters a lot in fast-paced games too, so you ideally want servers in Europe, North America, Asia, and so on. You could orchestrate all of this with Kubernetes and Docker, but it’s a serious amount of work.

There’s a premade solution called Agones built specifically for scaling game servers on Kubernetes, but I didn’t try it.

Bandwidth is another concern. Providers like Hetzner give you a monthly allowance (around 20 TB), and exceeding it means extra fees. (highly depends on the location, US hetzner servers give less bandwidth)

Fast-paced games can burn through bandwidth quickly. If you’re curious, open a Source engine game and run net_graph 1 in the console to see your real-time network usage.

The “in” and “out” values represent:

in data received per second (server → you)
out data sent per second (you → server)

To put some numbers on it: assume a 24-player server where each player consumes around 7.21 KB/s inbound. That’s roughly 173 KB/s total, which adds up to about 450 GB per month.

⚠️ That estimate is based on a rough player count approximation, but the math scales linearly with player count and tickrate. High-tickrate servers like 128-tick CS2 use significantly more.

For a cheap Hetzner VPS with 20 TB included, this isn’t a major concern. In my tests, the bottlenecks were CPU and RAM long before bandwidth became an issue.

Scaling WebRTC game servers (P2P model)

WebRTC can be peer-to-peer, which is appealing, no server relaying game data means much lower infrastructure costs at scale. Right?

The basic flow is straightforward:

Client A wants to connect to Client B
Both connect to a signaling server (usually a simple WebSocket)
The signaling server helps them exchange connection metadata (SDP offers/answers, ICE candidates)
Using that information, they attempt to establish a direct connection
If successful, data flows directly between clients via WebRTC DataChannel

The catch: if either client sits behind a NAT or a restrictive firewall, direct communication may fail. In that case, WebRTC falls back to a TURN server, which relays all traffic between peers and suddenly you’re paying for bandwidth again.

ℹ️ Free TURN servers do exist, like the Cloudflare one.

The cheating problem

Without a central authoritative server, data flows directly between clients. This is dangerous, what if a client just lies? Never trust the client.

If you ever played the old Call of Duty games, you’ve seen this in action. Sometimes you’d join a match and quickly realize it was a hacked lobby. One player was the host, and the host was the authority.

Hacked COD4 lobby with fly hack, most common on console

This is why authoritative servers exist.

What do other web games use?

Krunker.io → WebSockets (Rust backend)
Slither.io → WebSockets
Haxball → WebRTC (UDP)

Most modern browsers support WebRTC well at this point. That said, I’m already familiar with WebSockets, I prefer an authoritative server model, and I already have VPSes ready to go. I decided to stick with WebSockets for now, and let’s be honest, I don’t expect this to scale to millions of players 💀

WebSockets will be fine for my use case. I’ll hit other bottlenecks long before I hit the limits of the transport layer.

Starting small: multiplayer Pong

2017. Definitely a GOTY.

Before tackling anything complex, this was my first multiplayer project. A classic Pong game using Node.js and Socket.io, built in high school around ~2017

The game state was minimal:

Paddle positions (y-coordinate)
Ball position (x, y)
Ball velocity (vx, vy)

Since your client controls the left paddle, I could instantly update its Y position based on mouse movement, without waiting for the server to confirm. This made the paddle feel responsive, even if the local position briefly diverged from the server’s authoritative state.

Client-to-server messages looked like this:

{
  "type": "move_paddle",
  "y": 150
}

Server trusts the client here. Not great, but the worst you can do is teleport a paddle in Pong.

The server held the authoritative game state with a simple clients array:

// server.ts
class Client {
  gameStarted: boolean; // used for matchmaking
  posX: number;
  posY: number;

  constructor(public id: string) {
    // socket id
    this.gameStarted = false;
    this.posX = 0;
    this.posY = 0;
  }
}

I built a basic matchmaking system where players enter their name and get paired together.

The client used requestAnimationFrame to render at the browser’s refresh rate (60 FPS, handled internally by p5.js), while the server ran a game loop at a fixed 60 ticks per second with setInterval. At the time I didn’t have a high-refresh-rate monitor, so I didn’t realize how mismatched tickrates could degrade the experience.

Server-to-client messages looked like this:

{
  "type": "game_state",
  "ball": { "x": 200, "y": 150 },
  "paddles": [
    { "id": "player1", "y": 120 },
    { "id": "player2", "y": 180 }
  ]
}

This approach had a real flaw: the server’s tickrate didn’t match the client’s framerate, leading to choppy ball movement. At minimum, we could interpolate between server updates to smooth things out.

⚠️ We’re sending stringified JSON here. In a real game, you’d want binary serialization (Protocol Buffers, FlatBuffers, MessagePack) to shrink packet size, plus delta compression to only send what actually changed since the last update.

It’s alive!

This was my first multiplayer game. Simple, but it worked!

I added a chat later, easy to do since players were already exchanging packets with the server.

I hosted it on a free Heroku dyno, back when Heroku had a generous free tier.

The dyno would sleep after 30 minutes of inactivity, so the first player to join had to wait for it to wake up. A bit annoying, but it was free.

Why I ended up building my own Roblox-like engine

After Pong, I kept making other multiplayer games like a top-down 2D shooter called “Akrely” that I never released (~2018). They were fun, and I learned a ton about networking

But every time I started a new multiplayer project, I found myself reimplementing the same boilerplate: networking code, the game loop, rendering, serialization, event systems, input handling you name it.

I play a lot of Source engine games, which are famous for their massive library of player-made mods and custom servers. Then I looked at Roblox a game engine with a built-in multiplayer system. Even though I don’t really play it, the concept was immediately appealing: just write a few lines of script (Lua in Roblox’s case) and have a multiplayer game running.

I was sold. Let’s build that, but for the browser.

But wait, how? What architecture? How much will it cost? How long will it take?

Only one way to find out.

Why not use an existing engine?

I don’t use Unity, Unreal, or Godot.

I want to build this from “scratch” (using libraries, obviously, but not a full engine), because that gives me:

Fast first-load times
A native web experience
No Unity splash screen, no Godot export bloat, no Unreal on Linux headaches

Those engines produce WebGL exports via Emscripten, which generates a WASM binary plus JS glue code that’s typically several megabytes. It works fine for many use cases Unity WebGL games are pretty common, but that overhead isn’t something I want to carry.

Prototype 1: OOP

Project setup

I started with separate repos for frontend and backend. The initial prototype used a simple OOP approach: a base GameObject class with subclasses for players, NPCs, items, and so on.

The split looked like this:

multiroblox-back Node.js, cannon.js (physics), WebSocket server
multiroblox-front TypeScript, Three.js (rendering), WebSocket client

2022 prototype

Everything was cubes. Not exactly a graphical showcase.

Backend: base GameObject class

GameObject is an abstract class that all game objects extend. It handles the basic properties (position, rotation) and physics wiring (shape for collisions, body for simulation).

The Serializable interface marks classes that can be converted to a network-friendly format (JSON or binary).

// GameObject.ts
// BACKEND
export abstract class GameObject implements Serializable {
  type: TypeGameObject;
  protected body?: Body;
  protected shape?: Shape;
  public id: string;

  constructor();

  abstract createShape(): void;
  abstract createBody(): void;

  getPosition(): Vec3;
  getRotation(): Quaternion;
  setPosition(vec3: Vec3): void;

  addToWorld(world: World): void;

  serialize(): any;

  abstract update(dt: number): void;
}
// Simplified  full implementation omitted

From there, I could extend it to create specific game objects. Here’s the Cube class:

// Cube.ts
// BACKEND
export interface SerializedCube {
  position: {
    x: number;
    y: number;
    z: number;
  };
  rotation: {
    x: number;
    y: number;
    z: number;
    w: number;
  };
  size: number;
}

export class Cube extends GameObject implements Serializable {
  type: TypeGameObject = TypeGameObject.CUBE;
  size: number;
  color: number;
  constructor(position: Vec3 = Vec3.ZERO, size = 1, color = 0xffffff) {
    super();
    this.size = size;
    this.color = color;
    this.createShape();
    this.createBody();
    this.setPosition(position);
  }
  createShape(): void {
    this.shape = new Box(new Vec3(this.size, this.size, this.size));
  }
  createBody(): void {
    this.body = new Body({ mass: 10000 });
    this.body.addShape(this.shape!);
  }
  serialize(): SerializedCube {
    return {
      position: this.getPosition(),
      rotation: this.getRotation(),
      color: this.color,
      size: this.size,
      type: this.type, // used to know which class to instantiate on deserialization
      id: this.id,
    };
  }

  update(dt: number) {
    return; // no special update logic for now
  }
}

Frontend: NetworkGameObject

On the frontend, I defined a NetworkGameObject interface to mark objects that can be synchronized over the network:

// gameobject.ts
// FRONTEND - src/gameobjects/gameobject.ts
export interface NetworkGameObject {
  sync(data: any): void;
  update(lerpValue: number): void; // The lerp is handled at higher level in the game loop
}

The Cube class creates the Three.js mesh. NetworkCube extends it to handle server sync, it stores nextPosition and nextRotation from incoming updates, then smoothly interpolates using lerp and slerp to avoid jitter between ticks.

// cube.ts
// FRONTEND - src/gameobjects/cube.ts
import * as THREE from "three";
import { Renderable } from "../interfaces";
import { Renderer } from "../renderer";
import { NetworkGameObject } from "./gameobject";

export class Cube implements Renderable {
  mesh: THREE.Mesh;
  material: THREE.MeshPhongMaterial;
  constructor(size: number = 1, color: number) {
    // Rendered size = Physics size * 2
    const geometry = new THREE.BoxGeometry(size * 2, size * 2, size * 2);
    this.material = new THREE.MeshPhongMaterial();
    this.material.color = new THREE.Color(color);
    this.mesh = new THREE.Mesh(geometry, this.material);
    this.mesh.receiveShadow = true;
    this.mesh.castShadow = true;
  }
  addToScene() {
    Renderer.instance.scene.add(this.mesh);
  }
}

export class NetworkCube extends Cube implements NetworkGameObject {
  public id: String;
  public nextPosition = new THREE.Vector3();
  public nextRotation = new THREE.Quaternion();

  constructor(id: String, size: number, color: number) {
    super(size, color);
    this.id = id;
  }

  sync(data: SerializedCube) {
    this.nextPosition = new THREE.Vector3(
      data.position.x,
      data.position.y,
      data.position.z,
    );
    this.nextRotation = new THREE.Quaternion(
      data.rotation.x,
      data.rotation.y,
      data.rotation.z,
      data.rotation.w,
    );
  }
  update(lerpValue: number) {
    // Without interpolation, movement is visibly choppy:
    // this.mesh.position.copy(this.nextPosition);
    // this.mesh.rotation.setFromQuaternion(this.nextRotation);

    this.mesh.position.lerp(this.nextPosition, lerpValue);
    this.mesh.quaternion.slerp(this.nextRotation, lerpValue);
  }
}

Netcode: snapshot-based

I went with snapshot-based netcode, sending the full game state to clients on every tick.

Tickrate is how many times per second the server updates and broadcasts the game state. Higher tickrate means smoother gameplay, but also higher bandwidth usage and server load.

A naive snapshot

Here’s what a raw snapshot looked like in this prototype:

{
  "position": {
    "x": 165.89569158479551,
    "y": -0.800051185115476,
    "z": 47.85383001858688
  },
  "rotation": {
    "x": -0.00001084003292835272,
    "y": -0.03619627233611027,
    "z": 0.000027550383514014802,
    "w": 0.9993446997870356
  },
  "color": 16777215,
  "size": 0.2,
  "type": "CUBE",
  "id": "fvipvHJY8W"
}

{
  "position": {
    "x": 225.74027673479415,
    "y": -0.800055555679223,
    "z": 45.81825443369147
  },
  "rotation": {
    "x": 0.000008149242908244306,
    "y": 0.9108704402144395,
    "z": 0.000024894037988968568,
    "w": 0.4126924283984742
  },
  "color": 16777215,
  "size": 0.2,
  "type": "CUBE",
  "id": "4OpTLQ8ANU"
}

{
  "position": {
    "x": 0,
    "y": -1,
    "z": 0
  },
  "rotation": {
    "x": -0.7071067811865475,
    "y": 0,
    "z": 0,
    "w": 0.7071067811865476
  },
  "type": "GROUND",
  "id": "1VXYDT4O6p"
}

This was naive for a few reasons:

Sending 16 decimal places for a coordinate like 165.8956915... is overkill. Three decimal places (165.896) is fine for most games.
Repeating keys like "position" and "rotation" in every packet wastes bytes compared to binary formats like FlatBuffers or MessagePack.
No delta compression, if a cube barely moved, the server still sent its full state. Even the ground, which never moves, got broadcasted every tick.

20 ticks per second

At 20 ticks per second with 100 objects, this prototype was hitting 500+ KB/s per player. Binary encoding and delta compression could realistically cut that by an order of magnitude.

It worked… barely. I had a game loop, 3D rendering, and server-authoritative state. That was enough to keep going.

Moving away from OOP

Class hierarchies are fine until your project grows. Then they become a liability.

Want a cube that moves? Extend Cube. Now you want a cube that moves and shoots. Do you extend MovingCube? ShootingCube? MovingShootingCube?

Rigid inheritance trees work against you in games, where concepts rarely fit neatly into a single hierarchy. A Player is a Character is a GameObject, but what about a possessable turret, or an AI that behaves like a player? You end up with deep fragile trees, duplicated logic, and special-case workarounds everywhere just to share behavior.

Credit: OOP hell

What I needed was something more modular, where behaviors could be mixed, matched, and replaced per mini-game without rewriting large chunks of the codebase. It also needed to integrate cleanly with networking and state synchronization.

I put this prototype on hold for a few months, but the idea kept nagging at me.

Prototype 2: ECS

After hitting the limits of inheritance-based design, I started looking for an architecture that could scale with complexity. That’s when I found the Entity Component System (ECS) pattern.

Most of us default to OOP because it feels natural, objects bundle data and behavior together. But in game development, that coupling quickly becomes a problem. Game objects change roles, gain or lose abilities, and share behaviors in unpredictable ways, exactly the kind of flexibility that rigid class hierarchies struggle to handle.

ECS approaches the problem differently.

Instead of modelling what something is, it focuses on what it has and what systems act on it. This turns out to be a much better fit for dynamic game logic and networking.

ECS in a nutshell

Entities are just unique IDs, they represent existence, nothing more.
Components are pure data attached to entities (position, velocity, health, input state…).
Systems contain behavior and operate on all entities that have a matching set of components.

This makes behavior composable. An entity that can move has a Position and Velocity. An entity that can shoot has a Weapon component. An entity that does both has both, no inheritance, no special cases.

// Component
class Position {
  constructor(
    public x: number,
    public y: number,
    public z: number,
  ) {}
}

class Velocity {
  constructor(
    public vx: number,
    public vy: number,
    public vz: number,
  ) {}
}

// Entity
const entity = world.createEntity();
world.addComponent(entity, new Position(0, 0, 0));
world.addComponent(entity, new Velocity(1, 0, 0));

// System
function movementSystem(dt: number) {
  const entities = world.getEntitiesWithComponents(Position, Velocity);
  for (const entity of entities) {
    const pos = world.getComponent(entity, Position);
    const vel = world.getComponent(entity, Velocity);
    pos.x += vel.vx * dt;
    pos.y += vel.vy * dt;
    pos.z += vel.vz * dt;
  }
}

What I wanted from the engine

I restarted the project from scratch with a clear list of requirements. The engine needed to provide:

A networking layer (WebSocket-based)
A game loop
3D rendering
3D physics
Compatibility with low-end browsers
High flexibility and modularity
A scripting layer to inject game logic at runtime (think Lua scripts in Roblox)
Scalability (multiple server instances, room management, load balancing)

Monorepo setup

In the first prototype, I split things across two separate repos. That created friction every time I needed to share types between the frontend and backend, you’d normally codegen or manually duplicate them. I didn’t want that overhead.

So: monorepo.

The structure:

back Node.js + uWebSockets.js + Rapier.js (physics)
front TypeScript + Three.js
shared netcode types, ECS core, serialization

Netcode architecture decisions

I went with server authority only.

Everything is decided by the server. Clients do nothing more than send inputs and render the game state they receive. If you know netcode at all, you know this is the simplest possible architecture and also the laggiest if you’re far from the server.

And yes, that is exactly how this implementation works. 🤫

Despite that, the tradeoffs are worth it:

No cheating the server is authoritative. Clients can’t lie about their position or state.
Simplicity no client-side prediction, no reconciliation, no divergence to debug.
Consistency every player sees the same world.
Proper collisions with server-side physics, two cars colliding at 100 km/h resolve correctly. Client-side prediction would have each client extrapolating their own position, leading to rubber-banding when the server corrects them.
Server-only game logic the game script runs entirely on the server.

ℹ️ We’ll get into what scripts are later. Think of them as the runtime game logic attached when a game starts, similar to Lua scripts in Roblox.

Basic ECS setup

I wrote my own ECS implementation in TypeScript. The back, front, and shared packages all import ECS code from the shared folder.

Entity management is handled by an EntityManager singleton that creates/destroys entities and manages component attachment.

Components are simple, they just hold data:

// Component.ts
export class Component {
  constructor(public entityId: number) {}
}

A PositionComponent can extend this base class. Depending on whether a component needs to be synchronized over the network, it either extends NetworkComponent or plain Component.

Introducing NetworkComponents

Let’s take a simple cube.

To render it with Three.js:

const size = { width: 1, height: 1, depth: 1 };
const geometry = new THREE.BoxGeometry(size.width, size.height, size.depth);
const material = new THREE.MeshBasicMaterial({ color: 0x00ff00 });
const cube = new THREE.Mesh(geometry, material);
scene.add(cube);

If we think about what the frontend actually needs to represent this cube, we can decompose it into components:

Each visual property maps to an ECS component:

Color:

// ECS Component
ColorComponent: {
  hex: string;
}

// Three.js mapping
const material = new THREE.MeshBasicMaterial({ color: 0x00ff00 });

Size:

// ECS Component
SizeComponent: { width: number, height: number, depth: number }

// Three.js mapping
const geometry = new THREE.BoxGeometry(1, 1, 1);

Position:

// ECS Component
PositionComponent: { x: number, y: number, z: number }

// Three.js mapping
cube.position.set(x, y, z);

Rotation:

// ECS Component
RotationComponent: { x: number, y: number, z: number, w: number } // quaternion

// Three.js mapping
cube.quaternion.set(x, y, z, w);

NetworkComponents: beyond primitive shapes

I didn’t want to be limited to cubes and spheres. In Notblox, I use a ServerMeshComponent that references a 3D model file:

// ECS Component
ServerMeshComponent: {
  filePath: string;
} // path to .glb, .obj, etc.

// Three.js loading
const loader = new GLTFLoader();
loader.load(filePath, (gltf) => {
  scene.add(gltf.scene);
});

Models can be hosted on S3 with CDN caching for fast delivery, giving the flexibility to load any 3D asset dynamically rather than bundling everything upfront.

⚠️ This creates a dependency on external assets. You need to handle CDN downtime, slow connections, and missing files gracefully, otherwise your game silently has invisible objects.

Three.js provides the GLTFLoader for loading glTF/GLB models. GLB (binary glTF) is more efficient for web delivery. File size matters a lot for first-load experience.

NetworkComponents: syncing over the wire

I intentionally separated NetworkComponent from regular Component. A NetworkComponent is one that needs to be synchronized between server and clients, it exposes serialize() and deserialize() methods.

// NetworkComponent.ts
// shared/component/NetworkComponent.ts
export abstract class NetworkComponent extends Component {
  updated: boolean = true;
  constructor(
    entityId: number,
    public type: SerializedComponentType = SerializedComponentType.NONE,
  ) {
    super(entityId);
  }

  abstract serialize(): any;
  abstract deserialize(data: any): void;
}

Here’s the PositionComponent as a concrete example:

// PositionComponent.ts
// shared/component/PositionComponent.ts
export class PositionComponent extends NetworkComponent {
  constructor(
    entityId: number,
    public x: number,
    public y: number,
    public z: number,
  ) {
    super(entityId, SerializedComponentType.POSITION);
  }
  deserialize(data: SerializedPositionComponent): void {
    this.x = data.x;
    this.y = data.y;
    this.z = data.z;
  }
  serialize(): SerializedPositionComponent {
    return {
      x: Number(this.x.toFixed(2)), // quantize to 2 decimal places
      y: Number(this.y.toFixed(2)),
      z: Number(this.z.toFixed(2)),
    };
  }
}

export interface SerializedPositionComponent extends SerializedComponent {
  x: number;
  y: number;
  z: number;
}

Since this lives in the shared folder, both the frontend and backend use the exact same serialization code, no codegen, no drift.

The SerializedComponent interface and its type enum look like this:

// SerializedComponent.ts
// shared/component/SerializedComponent.ts
export interface SerializedComponent {
  t?: SerializedComponentType; // discriminator sent over the wire
}

export enum SerializedComponentType {
  NONE = 0,
  POSITION = 1,
  ROTATION = 2,
  SIZE = 3,
  COLOR = 4,
  ENTITY_DESTROYED_EVENT = 5,
  SINGLE_SIZE = 6,

  STATE = 7, // used for animations

  CHAT_LIST = 8,
  MESSAGE = 9,

  SERVER_MESH = 10,
  PROXIMITY_PROMPT = 11,
  TEXT = 12,
  VEHICLE = 13,
  PLAYER = 14,
  VEHICLE_OCCUPANCY = 15,
  COMPONENT_REMOVED_EVENT = 16,
  WHEEL = 17,
  INVISIBLE = 18,
}

Putting it all together, here’s what creating a cube entity looks like on the server:

// Cube.ts
// back/src/ecs/entity/Cube.ts
const cubeEntity = EntityManager.createEntity(SerializedEntityType.CUBE);

const positionComponent = new PositionComponent(
  cubeEntity.id,
  position.x,
  position.y,
  position.z,
);
cubeEntity.addComponent(positionComponent);

cubeEntity.addComponent(rotationComponent);

const serverMeshComponent = new ServerMeshComponent(
  cubeEntity.id,
  "https://notbloxo.fra1.cdn.digitaloceanspaces.com/Notblox-Assets/base/Crate.glb",
);
cubeEntity.addComponent(serverMeshComponent);

const sizeComponent = new SizeComponent(cubeEntity.id, 1, 1, 1);
cubeEntity.addComponent(sizeComponent);

const colorComponent = new ColorComponent(cubeEntity.id, color ?? "default");
cubeEntity.addComponent(colorComponent);

why?

Tue, 06 Jan 2026 00:00:00 GMT

I’ve always wanted a place to show what I do, most of my projects end up in private GitHub repos I never touch again..

Nothing here has to be perfect!

Developing is messy, full of trial and error, and that’s okay. I just want to show some projects I work on, the experiments I try..

Hopefully this can inspire or help someone, or at least give a peek into stuff I’m working on in my free time :)

There is this blog I often often read: https://fabiensanglard.net/, even tho I don’t know much about low level programming, it’s always a fun read. why not make my own?

iercan's dev blog

homelab 101

the hardware

opening them up

very loud fan

proxmox

should you put Tailscale everywhere?

securing a VPS

the new way

the danger

my policy

the tag

the grant

the SSH rules

the test

what’s left

risk 1: it still sees my devices

risk 2: my own connections

risk 3: my Tailscale account

risk 4: my own devices

that’s all!

Footnotes

this blog runs on astro now

why Astro?

markdown all the way

content

adding RSS

build and deploy

problem: the first deploy failed

that’s all!

Every ThinkPad in one table

searching and filtering

every generation side by side

one page per model

you can also ask an LLM

how does it work?

problem 1: JSON inside JSON

problem 2: the specs are sentences

that’s all!

Building a multiplayer Roblox-like engine in the browser

TCP or UDP?

Scaling WebSocket game servers

Scaling WebRTC game servers (P2P model)

The cheating problem

What do other web games use?

Starting small: multiplayer Pong

It’s alive!

Why I ended up building my own Roblox-like engine

Why not use an existing engine?

Prototype 1: OOP

Project setup

Backend: base GameObject class

Frontend: NetworkGameObject

Netcode: snapshot-based

A naive snapshot

Moving away from OOP

Prototype 2: ECS

ECS in a nutshell

What I wanted from the engine

Monorepo setup

Netcode architecture decisions

Basic ECS setup

Introducing NetworkComponents

NetworkComponents: beyond primitive shapes

NetworkComponents: syncing over the wire

why?