DEV Community: Shri

Mobile Strategy Games Don't Have a Monetisation Problem - They Have a Game Problem

Shri — Thu, 28 May 2026 07:10:56 +0000

A few months ago, my partner got me playing one of those mobile strategy games - you know the type - build a city, train troops, join an alliance, fight other players etc.. They had already tried two others before - one shut down, and the other didn’t quite stick.

I avoided playing any of the previous ones, mainly on principle - I didn’t want to play a P2W game. But then they seemed to be having so much fun, so I thought I’d give it a go.

I’m not proud of it. I keep thinking that I should quit, that I shouldn’t spend money on it.

What keeps me in it?

The community is genuinely good. The alliance I’m in has brought together smart, funny, generous people from across the world who I wouldn’t have met any other way. We coordinate across time zones. We celebrate each other’s real-life milestones. We’ve built something that feels, improbably, like a small society.

The game, though. The game grates at me constantly.

And the more I’ve thought about why, the more I’ve come to an uncomfortable conclusion: there is no game there. There never was.

Monetisation as Design

Looking in from the outside, I figured these were games which allowed you to skip time / effort by spending money. I was woefully naive.

Every single aspect of the game is built to:

Feel like what you want is just out of reach
Train you to spend (gems, speed ups, stacks of other currency types)
Manufacture social pressure to level up, support your alliance
Blur the line between in-game currency and real money
Make ego bruising a de-facto standard, forcing impulsive spend
Design specific events to funnel actions into spending

Let’s take each of these in turn

Just out of reach

There is the basic timer-gating of everything as you’d expect, but it gets more sophisticated. At first, there is a cap of 30 for the city level.

Everybody races there - spending money. The F2P players don’t stand a chance. You need to spend hundreds of dollars to get there. Then it extends into fire crystal. The free players are forever falling even further behind.

Spend, spend, spend

When I first started playing, I hoarded stuff - gems, speed ups, chests etc. Then I realised that just slows me down. The “way to play the game” is to spend everything as soon as you get it. That rewards you with more stuff, which you then spend.

There are red dots everywhere guiding you through all the stuff you get “for free” and you’ll “earn” by spending other currency.

The faster you can spend stuff, the faster you get stuff, and the faster you grow.

Social Pressure

Most servers end up with a Non-Aggression-Pact or NAP alliances - starting with the 10 most powerful alliances. This list tends to shrink as the wheat is separated from the chaff. No prizes for guessing how you end up a powerful alliance.

To be able to be competitive with the other alliances, we need to grow. If the other alliances have players that spend a lot of money, we’ll need to match them.

The top two alliances in our server have decided that they will rotate the “presidency” between them - because the other alliances are not strong enough. They want to encourage the other alliances to grow through competition or merges.

Why is that fair? Because, otherwise, it’ll demotivate the “whales” from spending money or playing the game. That was the literal justification from the leader of the top alliance.

In-game currency vs real money

The game trains you to click buttons - you get rewards. Some of them give you gems, some of them give you speed ups, resources - all useful stuff. It’s easy, and attractive to click the buttons.

There are paid packs - and they have attractive buttons too - but they look different enough that you wouldn’t accidentally buy something.

There is always a pack advertised when you open the game. You get into the habit of closing it quickly. Except, occasionally, they’ll offer a pack for free. So you “buy it.” You are being taught that buying a pack is easy, simple and profitable.

They have another event which is a series of purchases. The first one is free, which unlocks one for £0.99, which unlocks two more free ones, then £1.99 and so on. The more expensive packs are ranked as epic / mythic etc. so it feels aspirational.

But wait - £0.99 for an extra build queue - that’s hands down the best deal ever - and it’s only a pound. It’s worth it at the start of the game. I’ll get that. I’ve just trained myself that it’s ok to spend money in the game. The floodgates have opened.

I found myself buying a pack the other day, on autopilot. I knew what was happening, but I couldn’t stop myself. It was only a pound - but it was 4000% of gem value - most of the packs are only 2000% - 3000%. What a good deal!

Buying Ego

Every single thing in this game is ranked. Most powerful player, alliance, heroes, troops - you name it - there is a ranking for it somewhere. Events (most of which are purely about spending) are also ranked.

Who wants to be ranked 523?

These rankings set up the sharper edge.

A powerful player from another alliance attacked everyone in our alliance. We were burning.

The top player in our alliance retaliated by burning almost everyone in their alliance. He burned through hundreds of dollars trying to burn the attacking player - and ultimately had to give up.

I felt bad for that player. He had spent all this money, and because the game lets your soldiers die, which a lot of his did in the endeavour, he wasn’t that much more powerful than when he started. He might as well have set his money literally on fire.

Several weeks later, a player in our sister alliance was attacked. The attacker was small enough that a small group of us was able to “exact vengeance.” However, I felt my blood boil - “how dare they?” If they were stronger, would I have burned money for vengeance?

Events Funnel To Spend

Of course, all of the above is not enough. Now, everything is wound tight - obstacles to spending have been removed, and the pavlovian behaviour has been well trained.

The next step is events where you fight against other alliances. The rewards are just enough to make it interesting - but the competitive environment is electric. Squad chat is buzzing, the commanders are directing. You are teleporting, attacking, there are small fires.

It is still timer-gated. You can teleport every x minutes. Your troops need to be healed immediately, so you’ll need to spend speed ups.

New areas open up so you have to teleport, then time runs out. Your friends are being attacked and they want you to help them. You don’t have any ports left - so what do you do? You buy them with gems. The next teleport is twice as expensive. You run out of gems. What do you do?

Why it works

For me, it’s the people. It’s not just that though. The game rewards you for clicking. It gives you red dots to clear, and it doesn’t take any cognitive load. The game has many layers of complexity. That is interesting to peel back and figure out.

There are regular events you can participate in, and it feels good when you get better at it.

All of this though is underpinned by the social aspect. You are not just getting better at the game, others in the alliance are watching you get better at the game. The witness aspect is truly rewarding.

The next aspect is the electricity in the battles - whether it is fighting for a facility, or the events, the adrenaline is pumping, and your heart is pounding.

I remember, a few weeks ago a couple of us were garrisoned in a building with a couple of minutes left in the timer. The enemy literally surrounded us. There were perhaps a dozen red cities to our two or three blue ones.

We needed one more person to come and reinforce us. The air sparkled blue, flashes of lightning and someone ported in. They backed us up, and we won!

Another time, similar situation, we were woefully outnumbered, but we were just about holding it. Then someone teleports in, and starts burning the enemy cities. One by one, they get ported out. We hold the building. We win.

Of course, sometimes we lose - but that bonds us too.

The game creates intense relationships with people all across the world - with people we will probably never meet in real life. If we met these people in real life, we wouldn’t be able to talk to each other because most of them speak another language.

Well, let’s make it ethical

The obvious response is: build the same game with ethical monetisation. Cosmetics only. No pay-to-win. Keep the city builder, keep the alliance politics, keep the territory wars.

I don’t think that’ll work.

The engagement in these games - the reason people stay, the reason alliances form, the reason anyone cares about territory - is almost entirely downstream of the pressure. Remove the monetised pressure and you have to replace it with something else, or the game has no tension.

What keeps you logging in isn’t love of the game mechanics. It’s social obligation created by artificial scarcity. Fix the artificial scarcity and the logins stop. Which means the alliance coordination stops. Which means the community - the genuinely good thing these games accidentally create - stops.

Without the whales, there is nothing to rail against - so the free players would all just get along with little conflict.

There are times when we would turn up to take over a facility and smaller alliances would just leave the territory. They might have taken the facility already, but instead of trying to hold it, they just leave. They don’t want to recoup any potential damage.

Without the option of paying money to get more powerful - maybe everyone would just leave when someone clearly more powerful came along. Maybe people would focus more on the co-operative aspects. But the co-operative aspects aren’t necessarily fun by themselves - they’re the chores you do to be more powerful and fight in PvP.

Sure PvP takes skill, some tactics and practice - no question. However, these requirements are there only to legitimise it when people spend money. “It’s not just about spending money” - but if that’s the case, then why do so many people spend so much money?

This is not a strategy / city building game. It’s a how-quickly-can-I-drain-my-bank-account game.

Good Live Service Games

There are three good live service games that I point people to. Path of Exile (1 & 2), Guild Wars (1 & 2) and Eve Online.

They all focus on paying for convenience rather than pay to win, and of course cosmetics.

They are all very different games from this though. I have played PoE, and GW, both 1 and 2 for hundreds of hours but I did not build these intense relationships in there. In fact, I built no real friendships in those games.

But then, I didn’t really play PvP - I stuck to the PvE and never felt pulled into the competitive layer the way this mobile game pulled me in.

Eve Online would probably be the closer fit - and I really enjoyed it. The main problem I had with it was that it doesn’t force you into alliances (or corporations in their parlance) like these mobile games do.

The world feels humungous and difficult to navigate. On these mobile games, you quickly get a sense of the whole population on the server. You see the same people over and over again at facilities, or event leaderboards. You are forced into an alliance to survive and there is alliance chat front and centre.

Without the highly extractive spine of these mobile games, is it possible to create a game capable of high engagement and tight-knit communities?

The Fundamentals

To be able to make a game that creates the best of these mobile games without the worst of it, the first thing that needs to be set correctly is the incentive

not for the players, but for the ones creating the game.

A studio optimising for extraction will build different systems than one optimising for a game worth playing. Everything downstream follows from that choice.

This part is difficult to get right. It needs trust, and faith.

Grinding Gear Games, who made Path of Exile, mainly focused on building a really good game and trusted their player base to appreciate it.

I spent over £100 on Guild Wars 2 buying all the expansions and a bunch of stuff from the store. Content and features were gated behind these purchases, but I was happy to spend the money - this time I was also happy to unlock features I wanted.

I don’t care about cosmetics - I never have - and yet, I spent money on Path of Exile cosmetic packs. I can’t help it. I feel fantastic when I spend money with GGG buying things I don’t care about. I’ve spent over £100 on their packs.

I’ve spent maybe £50 on this mobile game - and I felt like a chump after _every_transaction.

Player Value

With community and bonding as the highest items of player value, intense shared player experiences become the central piece of the game.

The language barrier has to be lifted. Automated translations are a minimum requirement - and ideally better quality than what’s in these games.

These experiences should not be fully on the player schedule. Being forced into an encounter is part of the intensity of the experience. Without that, it’s easy to just forget about engaging.

It needs to be people-led - as it is now - the alliances are the core component. Negotiating with other alliances and players for non-aggression pacts, punishing poorly behaved players, are all important aspects of building the sense of community and belonging.

GGG uses seasonal resets to powerful effect. Having an end state after which the whole server starts again helps avoid constant power creep. It also gives players another chance to start from the beginning, using all the knowledge and experience they’ve gained.

I think it would still be important to allow people to pay for boosts. There will be people who would rather spend money on the game than time. I am not opposed to that - but it should not be the driving force. Spending money should not let a player overtake one who did not spend money. Pay for convenience, not power.

Competing to build something together could be a really rewarding ending for a season. Instead of more fighting in a server vs server where you might lose, having a clear and defined victory condition that is collaborative would leave everyone feeling positive. Once completed, they can bask in the joy of the finished task. Perhaps it could be a really difficult battle the server has to band together to win. People who were once enemies now backing you up. You finish the season with even more friends - forged in battle.

What I’m Left With

I keep wishing that I could make something different, that the world treated its people as better than just a money machine.

In the meantime, I am left paying for these small hits of community, of friends forged in fire. The cost, to my bank account, at least is small.

Sovereignty Over Convenience

Shri — Wed, 27 May 2026 08:54:20 +0000

I’ve recently been on a journey reclaiming sovereignty over all of my data and infrastructure. I still remember the era before the cloud when you had to do everything yourself.

Cloud changed all of that, and it was really nice - and convenient. In the back of my mind, though, there was a tiny little scratch.

Security is inversely proportional to convenience

– Professor Evi Nemeth

GitHub was so convenient compared to running your own infrastructure. The scratch stayed small. Then Microsoft bought GitHub.

Over the last few years, things changed. Trust in big tech has eroded so heavily.

LLM’s have also made things a lot worse - in two ways.

Every organisation seems to be trusting LLM’s to write and deploy code. I’ve got the LLM’s to write code - and I would not trust that anywhere near security critical code. GitHub is using non-deterministic, hallucination-prone models to make security decisions.

Secondly, LLM’s are vacuuming up all the data they can get their hands on - no permission sought.

However, my much bigger issue is that I have no choice in the matter. My consent was not sought - my concerns were not voiced. My only choice is to carry on in their boat or get out.

Ultimately, though, way down deep, in the very core of my questions, there were two basic questions.

What is all my stuff on the cloud being used for?
How safe is it?

As each day passed, and my trust in the big tech eroded, the pain of setting up the infrastructure started to pale in comparison to the pain of my data being used without my informed consent.

I had to act. But first - an inventory!

My cloud data mainly lived across:

GitHub
- multiple repos, public & private
- blog site (on github pages with custom domain)
Google
- Emails
- Documents
- Photos
Facebook
- Photos
- Posts
- who knows what else

As a starting point, I wanted to tackle my public infra - mainly GitHub.

I ultimately wanted to feel as safe as I felt before the trust in the cloud was eroded, with the minimal effort. That meant:

Truly private storage for my private data
Strong GDPR support.
Hosting the public aspects on trustworthy platforms
Resilience. I’d need to build that manually, starting with offsite backups.
High availability. I’d need to get as close to that as I reasonably could - so I also needed monitoring

It would be no small task, and the biggest pain point would be ongoing maintenance and supporting it if something goes wrong.

I would need to document how every bit ties together, make it easy enough to redeploy services, reinstall servers and to monitor them, all the while also keeping it safe, secure and minimising any attack surface.

Right… There is a cost to getting all of these “for free” on the cloud.

Tooling & Services

Cloud IaC

Documenting all of this would be tricky - unless I use Infrastructure as code. I’d used terraform quite a bit and was comfortable with it - well, opentofu now. However, I knew that I would want to separate things into small units and that I would want to make re-usable components - for static site hosting for example. These features were easier with pulumi - and I can skip the cloud features.

Bare Metal IaC

That would however, not cover any server configuration. I would have servers both at home and remotely. I could just configure them once and hope for the best - but they will inevitably need a full upgrade, which might need config tweaking again. I might need to reinstall, and then I’d need to figure out all the configuration I did.

I have been pretty disciplined in the past about noting config changes so I could reproduce it later, but that’s neither an easy nor a pleasant task.

I wanted something automated - I considered something likeetckeeper, but that would store every config change, including from package updates. I wanted to track only my changes.

I wondered if overlayfscould be a solution, with my version overlaid over the packaged installed/etc - but it wasn’t really designed for such a use case. I’d also need to somehow redirect the package installs to a different place than /etc

Another option was stow. I was already using it for my dotfiles. I could haveroot stow files into /etc. This option felt the most straightforward until I had to re-install my home server (omv -> proxmox).

I wanted to be able to automate any reinstalls further - not just /etc, but also package installs. The most straightforward tool fit for this was ansible. I did consider chef, puppet, etc. but they offered a lot of features I didn’t need. The only feature that ansible didn’t give me that I wanted was state management like pulumi, but from what I could see, the alternatives did not provide that.

In the end, I just decided to manually clean up after ansible when it leaves any files, config or packages behind. Worst case, I also had the nuclear option of wiping and reinstalling everything to get rid of any cruft since I configure everything through ansible. I’ve already done that once.

Cloud Services

There are specific cloud services I would still need. I need offsite backup - in case something happens to my server. I also need to host my blog and my public sources repos.

In Europe, I found two strong candidates: Hetzner, immediately felt more enterprise level, which was confirmed with the pricing.Scaleway felt friendlier and the pricing was more accessible.

Ultimately, I picked Scaleway because the pricing was cheaper at lower usage levels, giving me a bit of time to ramp up. The interface was also easier to understand and navigate.

Scaleway has Object Storage for offsite backup and for static site hosting.

I considered hosting a forgejo instance but that meant a VPS, a database server, patches, potential issues around bots / LLM training, higher level of complexity, and cost. It would also add friction to user interaction - they’d have to register to my instance, which would have only my code.

I instead opted for codeberg. If it’s good enough for zig, it’ll be good enough for me.

forgejo might become interesting again after it integratesForgeFed, which would make cross-instance collaboration easier.

Backup

For backup, restic was best fit compared to borg. It has better S3/Object-Storage backend support natively. More importantly, borg needs to be a running service, and so more maintenance. With restic, I can just sftp to the server for all operations, backup, view or restore.

Monitoring

The last time I did monitoring and alerting in production, I was using munin / monit / nagios. Everyone has moved on. I’d evaluated datadog, grafana, New Relic etc in a previous job, but of course, I am not opting for a cloud option.

While there are a few options out there, prometheusand grafana came up as fairly standard, and I wanted more experience in them, so they were picked for the stack.

Migrating

The first step was to back everything up.

I set up restic on my desktop, backing up to my server (atlas), which backed everything up to Scaleway’s object storage.

That took many, many hours to complete.

The next step was to tidy up my home infrastructure.

atlas

The server I have was already running omv andplex. While 15+ years old, it is a dual cpu box with 32G of RAM. It had 4 2T magnetic drives on mdadm using raid-6

I had three more 2T drives on my desktop that I wanted to move over to the server because it’ll be good to have the space.

I would also need additional services on the box.

prometheus and grafana and any other related services for monitoring and alerting.
codeberg actions runner in a contained environment to mitigate security risks
forgejo instance for my private source repos

I could still run debian with docker and deploy services on there. However, I wanted more isolation for the codeberg actions runner - just in case it managed to escape the container.

Proxmox Virtual Environmentwas a good fit. I’d used it years earlier, but wiped it after it’d fallen behind on updates and it felt like a huge task to upgrade it. This time, I’ll be using ansible so I could even wipe and reinstall if I had to.

Proxmox would also bring zfs, with raidz2 which provided safer array expansion and scrubbing to catch bitrot early.

There is a single SSD on atlas, and installing proxmox on there was the easy part. I then had to find temporary storage for around 4T of data.

I spread them out on my desktop over several drives, I had some space on my M2 SSD and my games drives which had a lot of space but no resilience. I put all of my data which I could recreate if I needed to on there - e.g. my blu ray rips.

All the more valuable data luckily fit on my desktop’s raid5.

Worst case, all of it was also backed up using restic to a scaleway storage bucket.

Base Config

atlas remains for the most part the core install of proxmox.

Apart from basics like neovim, it’ll also host the zfs storage:

through sftp for restic
nfsv4 for the other linux boxes
samba (when I need shares on my dual boot or vm’s)
ssh for git
data directories for all the services running in docker.

It also hosts the LXC containers for:

Codeberg Actions Runner (ussain)
- on a separate network so that it can’t access my LAN
docker services (loom)
- prometheus
- blackbox-exporter (web site monitoring)
- prometheus-pve-exporter (for proxmox stats)
- grafana
- jellyfin (privacy respecting alternative to plex)

Since all of these are deployed via ansible with the data stored in atlas’ zfs, it’s easy enough to change the configuration and deploy them to another lxc. Only other manual step would be to delete the previous instance since ansible doesn’t clean up after itself.

Scaleway

Scaleway will host my blog site. I’d been meaning to rename it anyway, so this was a good opportunity to do that. My website uses hugowhich outputs static html, so I can host it on S3 like Object Store. The problem with that it gives you a long domain name and doesn’t support custom domains directly.

To be able to route it via a custom domain, the simplest solution isEdge Services on Scaleway. On AWS, I’d used CloudFront - but it is annoying, and you needed to set up http -> https redirect as well.

Scaleway also has an additional cost component. You need to pay €0.99/month minimum. That’ll give you one pipeline (i.e. one domain) and it’s €4 for each additional pipeline.

I wanted to host two domains - so that’d set me back €4.99/month. Doesn’t break the bank, but it’s also much more expensive than AWS. A small price to pay for privacy and sovereignty.

I found the edge services quite fiddly though. I could delete it from the console, but pulumi didn’t detect the changes correctly. I also had some issues which meant that it burned through generating 50 ssl certificates and required I wait 7 days before trying again.

At this point, I decided to deploy a VPS instead.

I knew that I would eventually need a VPS for remark42to support commenting on my blog. A VPS is around €7, only €1 more than the Edge Services pipelines.

I used pulumi to provision the VPS(hera), including ipv4 and ipv6, and used ansible to configure it.

I also put together a pulumi stack for ansible outputs. It picks up the bucket s3 urls and writes a config file for ansible. ansible then uses this to configure caddy to route the relevant domains to their s3 buckets. This automation helps to keep the cloud state synced with the server configuration without manual intervention.

What it does have though is a node exporter for prometheus. However, it’s not easy for prometheus to connect to it. The safe option I could come up with was to use wireguard between the docker lxc (loom) and hera.

I also added a firewall rule on loom to prevent any new connections originating from hera. I want prometheus to be able to access hera, but not the other way around. That adds an extra layer of protection if hera is ever compromised.

Again, all of this is configured through ansible, so if hera is ever compromised, I could just wipe it and reconfigure it with one command.

Deploying the websites

Now that the websites were configured, I wanted to give the visitors more than an error page.

This was also the appropriate time to move my repo from GitHub to codeberg. I created a new repo on codeberg and pushed the repo up. I just edited.git/config instead of removing the origin and adding it back in.

The site was previously using both GitHub Actions and GitHub Pages. It would now be using forgejo actions and rclone to push to Scaleway. But wait - it needed auth.

So far, codeberg has been the one bit of infrastructure I couldn’t code. I had to actually go on to the website and click through the UI manually. It has an API, but pulumi does not support it.

I did however put together a little script which takes a CODEBERG_TOKEN env var, picks up the secret key from pulumi outputs and sets it as a secret on the specified repo.

I have a function in pulumi for static sites which also creates and exports this token, which makes it pretty straightforward to add more static sites. This reusable functionality was the reason I wanted pulumi from the start. I’d done reusable components in terraform as well, but they were a lot clunkier.

I considered collecting web server logs, as I remembered doing back in the day - with apache and analysing them awstats. These days, it would probably be GoAccess. However the privacy concerns around storing ip addresses needed handling properly, so I put that on the backburner.

Monitoring & Alerting

Monitoring and Alerting was honestly the biggest reason why I kept putting off bringing everything in-house. Not the work involved in building or running it, but the feeling of being constantly on call - which I was for 13 years.

That was for multiple high profile, high traffic websites. This is my personal blog - it’s not a problem if the site is offline for a few hours - nobody is losing money. Still, the pavlovian response was one of stress.

I was able to work through it largely by reminding myself that there are no SLA’s.

I got prometheus to scrape all the data it can from the server, the lxc’s and my desktop. I pulled in some dashboards from grafana to visualise them. It’s nice to see a historical usage for my desktop and the server, including averages, growth rate etc.

However, alerting was the main reason for all of this.blackbox-exporter monitors my blog and another site I’ve got set up. This is valuable, and nice to see green across the board and that it checks expiry for the ssl certificate. I’d been burned in the past with certificate expiry and it’s nice to not have to worry.

When I set up the new site, I also noticed that I’d forgotten to set up a redirect from a previous domain. That domain had a lot of SEO juice, which was cut off for a while because I hadn’t tested it.

This time, I made sure to add all redirects to the blackbox_exporter tests.

I configured them to go to a channel in a discord server, the path of least resistance. A better option would probably be fluxer.appbut it doesn’t yet have a mobile app.

It triggered an alert the other day. My heart skipped a beat before I remembered that it was just my blog. It resolved itself while investigating it. I could find nothing wrong on the server, which was unlikely to be the culprit anyway.

It was probably the Object Storage Bucket, so I added the website endpoints to the monitoring as well. In the event of a future site failure, I will be able to see at a glance at which point the failure is.

For a moment, I regretted switching it all to my infrastructure - because it would not have gone down for a few minutes on GitHub. I then realised that I simply don’t know how often my site went down when it was on GitHub or for how long - it was never monitored.

Journey So Far

I am thrilled to have my blog live on my own infra instead of on GitHub’s. Having the whole setup documented in pulumi and ansible makes it much easier to maintain and manage. It also makes it much easier to take a look at how I set something up.

I also appreciate that I can redeploy all or parts of the services with ease if required, and that upgrades should be relatively pain-free.

The infrastructure that is deployed feels less opaque than when I had done similar things 15+ years ago, thanks to it all being managed via IaC.

Next Steps

I also have to pull everything down from google and facebook. I already have the file storage ready - I just need to pull everything down, then delete it from the cloud.

Email will be a bit more work. I am using mailbox.orgfor my new domain, which feels good enough. I have half a dozen email addresses. I can rationalise them down to three, but I also want to wipe out all the junk email in the process.

Google Photos will be trickier still, partly because I’ve not looked for a self-hosted solution for that yet. There is also the problem with how to provide access to my internal servers to the internet safely so that photos can be uploaded / downloaded from the phone when I’m out and about. Headscale might be one way to solve this.

I also want to put together a dashboard on grafana that will show me a comprehensive high level overview of my whole estate on one monitor - that’s an endeavour for another day.

Conclusion

So far in my journey, I have migrated key repos from GitHub, both private and public to safer places. I feel substantially safer already. Most of the repos were code, but one was my zettelkasten / second brain knowledge archive. This used to be a private repo on GitHub. It is now stored on atlas across from me in my room, encrypted and backed up to Scaleway. That was the biggest win of this whole process.

The rest of the data will come down here in time, and I have no doubt that I’ll feel safer by the end of it.

Am I actually safer? That is much harder to measure. I know that I have limited the attack surface as much as possible. Plus, my scale is so small that I am unlikely to be targeted.

On the other hand, GitHub and other cloud platforms have a lot of people worrying about and considering security and safety on a daily basis. They regularly patch the servers and track security vulnerabilities.

Am I actually safer? I don’t know - but I feel safer.

Only One Per Customer

Shri — Mon, 25 May 2026 13:44:52 +0000

henge pushes config to edge devices. Semantically, each device should connect once - except:

What if a device is misconfigured with the details for another device
What happens if a device disconnected, but we haven’t picked it up yet
How about if a device has a zombie connection and decides to reconnect
Any other cases I’d not thought about.

So, we need to figure out how to handle a second connection from the same device.

Allow multiple connections

For each device, we track multiple connections. Instead of a map to eachchannel, we’d have one to an array of chans ([]chan)

Every operation on channel then becomes a loop.

For the case where each correct case is most likely to be one device to one connection, this option has a lot of additional complexity, work and defect surface area.

Reject additional connections

This option is simpler. If a device is already connected, we reject any additional connections.

This option is certainly simpler than allowing multiple connections. However, we are dealing with a network and there are many reasons why a connection does not close properly.

To be able to mitigate some of the issues, we’d have to allow the user to manually clear an open connection so that a device can re-connect.

The endpoint is easy enough to write, but requiring user intervention is not something I like having as part of a product.

We could add a heartbeat, and close the connection down if it’s doesn’t receive a heartbeat for a configured amount of time. This reduces the reliance on user intervention by replacing it with wait time. Of course, it also now adds complexity.

Close existing connection on reconnect

How about on reconnect, we close any existing connections and reconnect to the new request?

Instead of one chan per connection, we now have a Subscription

type Subscription struct {
    stream   chan henge.ConfigChangedEvent // actual stream of events
    closeCmd chan struct{}                 // on msg, unsubscribe
}

And the connection code involves a little more of a dance:

func (c *ConfigEventBroker) Subscribe(deviceId string) *Subscription {
    c.mu.Lock()
    defer c.mu.Unlock()
    sub, found := c.channels[deviceId]
    if !found {
        sub = &Subscription{
            stream:   make(chan henge.ConfigChangedEvent, 1),
            closeCmd: make(chan struct{}, 1),
        }
        c.channels[deviceId] = sub
    } else {
        // already connected
        // close previous connection
        sub.closeCmd <- struct{}{}
    }

    return sub
}

and the connection itself respects the quit command:

    for {
        select {
        case snap := <-sub.stream:
            err = sendSSEEvent(w, f, Snapshot{
                Version: snap.Version,
                Values:  snap.Config,
            })
            if err != nil {
                slog.Warn("error while emitting sse event", "err", err)
                return
            }
        case <-sub.closeCmd:
            // client reconnected. We can close this one
            return
        case <-req.Context().Done():
            r.broker.Unsubscribe(deviceId)
            err = r.devices.SetConnected(deviceId, false)
            if err != nil {
                slog.Warn("unable to set connect status to disconnected", "err", err)
            }
            return
        }

We don't have to:

Track multiple connections
Have Heartbeats
Require user intervention

In the event of rapid reconnect flurry coinciding with a slow handler, it should
still behave correctly, albeit slower. This rare edge case is accepted. If a
device is reconnecting that quickly to a slow handler, there are probably much
bigger problems at play.

Always On

Shri — Tue, 14 Apr 2026 18:51:09 +0000

I knew as soon as my phone rang what it was about.

It was the same every time. I would drag myself up to answer the phone - my body, my mind screamed at me, but I had gotten good at overriding every instinct through sheer willpower. I could hear the apologetic tone on the other side, and I could recognise some of the voices after a while. I mustered up all of my strength to be and sound as awake as possible. I needed to be professional even if I was still in my underwear.

I had a glass of water on my bedside table. I’d pick that up and head to my office in the spare room. The computer was always on and always ready to go — like me I guess. I’d log on to the servers, and check the logs. If I can identify which one fell out of the group, I can restart just that one. If I was too late or if the issue had escalated, I’d have to restart the whole cluster — shut them all down, give them a few seconds, then bring each one up, while keeping an eye on them. I could do it half asleep after a while.

Falling back asleep wasn’t a breeze either - I was tired - exhausted - but I was now also wired. Waking up in the morning was harder - the alarm would go off and my body would be limp. I still remember the sheer power of will to drag myself into the shower, then carry on with the rest of the day.

Of 266 incidents over about two years, I answered 156.

I remember one particular night, though I do not remember how many times I’d woken up beforehand. I was already tired.

megabus.com had gone offline. I got an alert. “But someone else is on call tonight,” I told them. “We already tried them twice,” came the reply. I had to deal with this. I had to deal with this.

I remember sitting at my desk at home working on fixing it. At some point, something was different, though I don’t remember what. While I was working on fixing it, I remember being overcome with an overwhelming impulse to get up from the chair and walk away — I almost imagined myself walking away. I resisted and shut down that impulse. I fixed megabus as I had always done. In fixing megabus though, something broke inside me, somewhere deep, in the very core of my being. I was never the same again.

I analysed the system top to bottom, inside and out. I even waded through JVM internals.

It got incrementally better, more stable. I think I rewrote every component that wasn’t the core ticketing system. In the end, what pushed it over the line were two unexpected changes. Automated nightly restarts of each node in the cluster and a rate limiter.

On the 10th December 2012, the system had a sale event. We had a bank of screens on a wall with all the key stats for the system. It looked cool, and we felt a bit like we were on a TV show. At peak, nearly 15,000 concurrent sessions — six or seven times the average. Over 30,000 bookings in a single day, three times more than the normal amounts across all systems.

We watched it closely, all day. Nothing broke. Nothing screamed. Everyone smiled, but there was no celebration.

Did They Have a Problem That Year?

Shri — Tue, 14 Apr 2026 09:24:26 +0000

2008 was a heck of a year for kraya, and for me. We were already operating megabus.com in the UK, USA, and Canada, along with Oxford Tube, the sales website for coach usa - all for Stagecoach.

We were also working on the fringe website. We integrated the website with the brand spanking new ticketing system - which cost nearly £900k.

We were also hosting websites for Boots, Kellogg’s Food Service and dozens of other clients.

All of this was held together by three or four developers, two systems administrators and me.

On the 13 June (incidentally, I got married on the same date years later), as I was just getting ready for a wild night on the town, a call comes through - which John answers.

I still remember them laughing and then doing a double take “oh, you’re serious? let me get Shri”

It was the fringe. We’d already known that they were having trouble with their ticketing system. I’d even pitched in, made suggestions - looked at their code to try and help, but none of that was enough. I expected an update.

They wanted to know if we could put together an interim booking system for them over the weekend. I wasn’t sure. I told them I’d speak to my team and get back to them.

I wasn’t involved with the work on the fringe up until this point. I knew very little about it. I was focused on megabus.com. The US version of the site had a big marketing campaign happening in a few days and that was what I was meant to be focused on.

By the time I put the phone down, Chris, who had been the lead on the fringe already had a answer. “We can do it!”

“But how - it’s got to take more than a weekend - right?”

The fringe website was already built well and had a clean layer interfacing with the new ticketing system. In fact, that was the bulk of the work that year.

So.. Chris told me - all we would have to do is to implement the functionality within that thin layer, fattening it up.

He believed we could do it. I believed him.

I hopped in a cab, headed over to the fringe to talk it through. I didn’t promise them we’d be able to get something ready by Monday, but I promised we’d do our best.

We were in the office on the weekend, writing code. I remember working on the basket, sending diffs over email and generally having a good time.

I even had some megabus US fun to keep me entertained in the form of issues with loading sheets - I was already in the office, so it was one step easier to fix.

One of the bits of functionality which took a surprising amount of time was the seat allocation. None of us had to worry about that before - it was just capacity management on megabus. For the fringe though, we had to allocate actual seats with seat numbers and everything.

With the fringe we had multiple tables which all joined together (thanks hibernate) to encode a tremendous amount of detail about the seating plans - including their physical location on a map.

It was too much detail for us, so we had to simplify it all down to get it working in the timeframe. We kept most of the rest of the structures intact to keep the data migration easier once the ticketing system was fixed.

By Monday, we had each managed at the most 6 hours of sleep each of the previous three nights. I still have vivid memories of a suit of armour that we put together using packing material while we were waiting for bits of data or details of logic.

I broke the MySQL replication at 01:24, fixed by 01:32

I remember the delirium setting in. Email sent to the client with “fun fun fun fun fun fun fun” as the subject

There were random emails to my brother “I’m still here!”

I also remember making makeshift beds with bubblewrap to get a wee nap here and there. We were all so exhausted - pumped up on coffee and nicotine.

Finally at 03:35 on the Tue email to client: “DONE DONE DONE DONE DONE NODE NODE NODE NODE”

Then at 05:33, requesting a PostgreSQL server rebuild for megabus US for their marketing campaign.

At 10am on Tuesday, the fringe is finally able to sell tickets. The website promptly fell over from the load, but we nurse it back and it sells 65k+ tickets in the first week.

It would be at least two more weeks before the ticketing system is fixed and brought back in.

For the work we did for them that year, and the previous one, we effectively only charged about 30% - because that’s all they could afford. This year, we asked if they could put our name on the website.

Over the next two weeks(while megabus US was on their marketing campaign), we fought many battles. There were 750 duplicate bookings. Numerous customer complaints (thanks to our name being on the website) - almost all of them blaming us for the failure of the ticketing system. People did not understand that we put in the interim one, not the one that failed.

Press releases went out from the fringe - only two credited us. Both misspelt the company name. Both called us a web design company — which, we were not, had never been, and had no interest in becoming.

In truth, I wanted to be a hero - I think we all did. What we really wanted was an acknowledgement of what we had done - which was nowhere to be found. We got paid though - at least for a part of our effort.

For many years after that, I would tell people with pride - “did you know - I saved the fringe, back in 2008,” which was inevitably met with something like “oh, did they have a problem that year?”

What we Carried

Shri — Mon, 13 Apr 2026 19:02:04 +0000

I started my company in 2000. I was 17. I built megabus.com in 2003. I was 21.

It started off small, and little by little, I carried more and more. I became we, and we carried more and more. Before we realised, we were carrying a great deal. Ultimately, though, if something went seriously wrong, it would be on my shoulders.

The chart does not capture the scaling of the organisation, or other departments like tech support or hosting, which had dozens of clients.

Data mined by Claude from my emails, issue trackers and code repos

The section at the top is the number of active committers for that quarter. You can see my on my todd at the start and the rise and the fall of the dev team.

The very peak of it was in 2008. We built a booking system over the weekend for the Edinburgh festival fringe because their brand new £800k+ system could only handle one person at a time.

There were a handful of us building it while I was simultaneously prepping and managing the megabus US systems for a sales campaign. At the same time we were operating megabus across the UK, USA, and Canada, Oxford Tube, Coach USA, the Fringe website itself and numerous other smaller hosting clients like Boots, Kelloggs Food Service, and so on.

We were a total of ~4 developers and two systems administrators holding all of these together.

I was recently reminded of a story a friend of mine told me. Before he was my friend, he worked with me, and one of the things we did together was one the big megabus deployments when we migrated to a Java EE ticketing system.

One part of the migration was the data. I had developed a tool to migrate the data and on the evening - everything was prepared, we were off peak, and we had taken the site offline. He ran the script, which went on for a wee while and it failed. It was not meant to do that.

The way he tells the story, he told me about the failure. I come over, look at the errors, say “hmmm, that’s interesting,” and head off to have a cigarette. A few minutes later I go over to my desk type away furiously, then asked him to run it again.

It worked, and completed.

I remember that night. I don’t remember what the problem was or how I fixed it, but I do remember that moment when I went over to see how it had failed. In the short walk from my desk to his, I reiterated in my mind, all the possible backup plans - with the worst case scenario being to call off the migration on that day. We would do it another day. It would cost money, but it would be do-able. I was ok with that.

I was curious as to where my limits were, so I kept pushing, until I would meet with a wall.

There were no rails and there were no railings - just a cliff edge, unmarked… I didn’t know that - I expected a brick wall.

The worst of it would be only a few years later, in 2011. We built a new Java EE ticketing system for a fraction of what it should have cost in about 30% of the time it needed.

I personally responded to over 250 out of hours emergency tickets over an 18 month period. That was hard!

I had run off a cliff edge, and like the roadrunner in the cartoons, it took a while before I realised there was no ground beneath me.

A few years after I ran off the cliff, the company shut down. A few years later, I would start my active recovery journey through therapy. A few years later still, when I felt ready for a leadership role, I was asked to lead a problematic team - a role they struggled to fill for a while.

The team worked hard and delivered but struggled with the perception of poor delivery. Trust was thin, stress was high and morale was low. The situation was so bad that the week before I was supposed to start, the scrum master who was supposed to be my guide through it all quit.

I was warned by multiple people that this job was loaded with problems. I took on the job anyway, without a real guide, straight into multiple serious issues.

I loved it and managed to turn the whole thing around in my first week. Delivered key items, laid the foundations of trust and improved morale. It took a bit longer to bed everything down. Within weeks, I was asked if I would take on leading the entire digital team.

It was here, many years later, I got a sense of how unusual it was for such a tiny team to do so much.

It was here, many years later, I got a sense of how it is to have guardrails, to have support, peers to lean on.

It was here, for the first time I realised that the job didn’t have to be a lonely one.

Whatcha Thinking?

Shri — Mon, 13 Apr 2026 11:05:48 +0000

I loved working on megabus. I was in love with it. My girlfriend at the time had a habit of asking what I was thinking about when I looked deep in thought. The answer - every single time, was inevitably megabus. She eventually stopped asking.

I was 22 years old.

When I built the original prototype for megabus.com, I built it using PHP + PostgreSQL. I put together a document detailing my reasoning for these choices. I quoted 33 days for it, built it over six weeks and charged £13,200.

The support contract was £300/month - for one day a month. On the first day, megabus.com sold 200 orders.

When megabus had its first expansion, I was up overnight bringing new servers online and scaling it live. I loved it - my code was finally being tested.

Over a week, I’d probably burned through many days of effort. I remember the project manager specifically asking me to invoice for the extra work I put into it. I even said that I would - except I didn’t.

I’ve had a long time to think about this - why did I not send that invoice? I even had approval.

The answer, as with most things of this nature is complicated. I loved the work and I didn’t want it to end. I didn’t want a potential conflict trying to figure out what a reasonable amount was to charge. I felt that I should have done a better job in the first place - I felt responsible that I had not told them that scaling of this nature would not have worked without prep work.

I had not scaled anything before.

I was 22 years old.

I was super grateful that someone believed in me. I naively assumed that they saw all the extra effort I was putting in and that they would reward me for it - that they would have my back.

I remember adding a bunch of different bits of functionality because I wanted it there. I didn’t want to go through the process of quoting for it, and it getting potentially rejected, not to mention the waiting for decisions. One key bit of functionality I remember is adding in a percentage load column for the loading sheets. I built it, showed it - they loved it! It went live. I did not charge for it.

At this point, the vast majority of my time was spent on megabus - very little of it actually paid for.

At a glance, based on the emails sent, I probably spent a minimum of 10 days each month supporting megabus when I was charging for one day.

In Jan 2004 - I proposed doubling the contract to two days for £4,800/year. It probably kicked in in Feb 2004. By March 2004, the site exceeded that revenue each day.

In the following months, I probably spent, on average a minimum of at least double the time I was paid for. I should have charged for it.

I grew the team, and the support contract based on the minimum I needed to maintain the product - not based on the amount of time I was spending.

For my 28th birthday, my girlfriend at the time organised a cake which was a image representing kraya - which was basically megabus. I felt bad that she thought that kraya was the most important thing in my life - she was right - but it still felt bad. kraya had other clients at the time, but my time wasn’t monopolised by other clients, or indeed by kraya - my heart still belonged to megabus.

And it would all have been all fine too, except for a grave miscalculation I made.

In 2010, after trying to rebuild the ticketing system for £500k, and making some mistakes with people I trusted, kraya ended up in £150k in the hole. We needed some money urgently.

I was desperate and naively, I reached out to stagecoach for help. I thought they were my friend - that they would have my back.

They understandably lost a great deal of trust in my ability to manage and lead my company. I trusted the wrong person - but that was still my mistake. They were right.

I thought that I’d built up enough goodwill that they would help me through this. I’d felt I would have way more than that “in the bank” in terms of goodwill. I learned that professional relationships do not work that way that dark afternoon, standing outside my office on the phone, in the rain.

They didn’t make my life easier. Instead, I’d ended up rattling the cage - they were now panicked - realising their over-reliance on an organisation that could disappear at any point.

Instead of support, I had further actions, renegotiating the contract and what felt like punitive, and definitely invasive reporting obligations.

I was hurt and angry. I had poured my heart, my soul - hey, my very life into this product that I loved.

Suffice it to say - I got no help - no loan, no offer of investment - though they did suggest buying us outright - which I rejected.

I signed a contract under circumstances I would not wish on anyone.

The best I got from them was a challenge - if we were really spending more time than we were charging for - prove it. I did! We documented every minute we were spending - I wasted my time on spreadsheets, pointless meetings and work to try and rebuild the broken trust.

We went from £300k in the hole to £200k profit within a year. We charged for a whole year in support around 20% of what the system made in a day.

I was 28 years old.

Around the same time, I was also dealing with the operational aftermath of trying to build a java EE ticketing system over six months for £500k. I thought it would take a year and cost £1m. In hindsight, it needed two years and probably three million pounds.

Over 18 months, I personally answered over 250 out of hours emergency calls. We had a rota and others on call too - but I took the vast majority of these calls. I felt bad putting others through what I knew was gruelling.

All of this led me down a narrower and narrower path to a serious breakdown - though I didn’t know enough to name it until many years later. All I knew - all I felt was that something broke in me.

We managed to resolve all of the issues, but the deployment of that version kept getting pushed.

Stagecoach cancelled the contract in 2012. They had started building a ticketing system in-house two years prior - the cost of my grave mistake. I wasn’t able to make the meeting - I was in India, and at the same time as the meeting, I was meeting for the first time the one who is now my wife.

I was 28 years old. I spent the next 15 years putting myself back together.

How much did it cost them to build it inhouse? If I had charged for my time from the start, would we all have been better off?

I still feel something deep inside me every time I see a megabus - a sense of pride mixed in with a deep sense of sadness - not for what I lost - but for what could have been.

I am 44 years old, and I am starting again.

Publishing from hugo to dev.to

Shri — Tue, 23 Sep 2025 08:30:54 +0000

I have been pondering federating parts of my blog to dev.to for a bit more visibility.

However, I had a couple of issues:

With html (instead of markdown), it would not pick up the code blocks correctly
With markdown, it would render the relative links incorrectly

What I really wanted was a way to render the hugo markdown into Jekyll style (which is what forem wants) but with the links rendered.

This was a little more complicated than I would have liked.

Goals

At a minimum, I wanted two main things:

Render code blocks correctly
Relative URLs should be rendered as absolute (because they won’t work on dev.to)

Pre-existing Solutions

I found hugodevto which looked promising except:

Not a fan of having to manually update hundreds of posts with the devto id
Had a couple of fiddly bits to get it working (my plain text outputs had some troubles for unknown reasons)
It rendered image urls, but not regular urls.

Ultimately though, it felt a bit bulkier than what I was looking for

Using Hugo

I had done enough work with hugo and output formats to have a vague idea of how to make it work.

Limitations

There are a few limitations to doing it this way though. Hugo does not provide render hooks for everything . You will end up with html in the output. However, since Forem (and Jekyll) will just render them, it fits my use case. It won’t work as well if you try and use this to generate like for like markdown usable in Jekyll.

Define a new content type

We want a new content type which will output markdown

```toml [outputFormats.jekyll] mediaType = "text/markdown" baseName = "index" isPlainText = true isHTML = false notAlternative = true path = 'jekyll' # put the output in `public/jekyll` so it's easier to find [outputs] page = ['html', 'jekyll'] # Output all pages in our jekyll format as well ```

You also need a basic template before hugo will output our markdown files.

layouts/_default/single.jekyll.md

---
title: {{ .Title }}
published: true
date: {{ .Date }}
{{- with .Params.tags }}
tags: [{{ delimit . ", " }}]
{{- end }}
canonical_url: {{ .Permalink }}
---

{{ .Content }}

With this, if you hugo build, it’ll render the .md files, but the content will be html.

Render code blocks as markdown

We can use the code block render hook to “convert them” back to markdown.

layouts/_default/_markup/render-codeblock.jekyll.md

Render absolute urls

I already have a pretty extensive render-link so updating it was just a case of making a copy of it and replacing relative url references with absolute ones.

It’s fine for it to be in html because Forem will still render it correctly. They could be rendered as markdown and it should work just as well.

layouts/_default/_markup/render-link.jekyll.md

{{ /* other content */ }}
  <a href="{{ printf "%s#%s" .PageInner.Permalink $u.Fragment | safeURL }}" {{ with .Title }}title="{{ . }}"{{ end }}>{{ $text }}</a>
{{ /* other content */ }}

Output

With these relatively minor changes, I was able to render markdown files I could then pop into dev.to and it works for the handful I set up.

Next Steps

Images

One big glaring omission is images - it’s not as relevant for me because I rarely use images.

I expect it to be easy enough to use the image render hook to achieve this.

Automation

Once the above two are done, it would be good to automate it. I could

get all the posts
get all the local posts
map them based on the canonical url (which is returned by the endpoint)
upload updated ones.

Not all my posts are technical, so I’d also want to add a field to the frontmatter (devto_published) and figure out a way to push updates only if there are changes.

Conclusion

I have a working solution for now - and if dev.to brings enough traffic / value, then I’ll consider spending a bit more time adding polish.

For the time being though, seems to work!

Feel free to use any of this code (such that it is) as you wish.

Using `locateFile` to have js and wasm in different locations with emscripten

Shri — Thu, 18 Sep 2025 09:15:42 +0000

Originally published at drone-ah.com

As part of building shine, I am using
lume and webassembly with zig.

zig, through emscripten generates both a js and wasm file, which, by default are
expected to be in the same directory.

I wanted to put them in different places, and struggled to get that working with
lume for a bit. I did eventually solve it though:

Include emscripten js file

Firstly, the js file output from emscripten should be included in you page
manually. I had used site.add which meant that it was loaded before we could
put the override for locateFile in window.Module.

I am using the
simple-blog theme, so I add the
following line to the top of src/index.vto

<script defer src="/js/shine.js"></script>

Override `Module`

You can override how emscripten finds the wasm file in the
Module Object.

This can be done in the html file in a script block, or even better, in a js
file that is included automatically.

js/main.js felt like a good place.

window.Module = {
  locateFile: function (path, scriptDirectory) {
    if (path === "shine.wasm") {
      return "/static/shine/shine.wasm";
    } else {
      return scriptDirectory + path;
    }
  },
};

Closing

With this setup, I can not only have the js and wasm files in different
locations, it's also easy to modify / augment the Module object.

Calling Javascript from Zig through WebAssembly

Shri — Wed, 17 Sep 2025 14:52:20 +0000

The next step for shine is to build a bridge between zig and javascript .

I am currently planning to using supabase for storage. Unsurprisingly, it does not have a zig sdk. It does, however, have a javascript sdk.

If I can write basic CRUD operations in javascript and call that from zig through webassembly, that could make that integration a lot easier.

Goals

There are a few ideal restrictions for me - mainly because writing javascript is not fun for me.

Use the Supabase js/ts library through zig
Use TypeScript as much as possible. (I don’t love TypeScript, but at least it’s not javascript)
Keep as much of the supabase related code in the web part so that deno and lume can handle any heavy lifting.

Options

I can’t use FFI(Foreign Function Interface):

extern "env" fn jsLog(ptr: [*]const u8, len: usize) void;

extern "env" fn jsLog(ptr: [*]const u8, len: usize) void;

const wasm = await WebAssembly.instantiateStreaming(fetch("prog.wasm"), {
env: {
jsLog: (ptr, len) => {
/* read from memory and console.log */
},
},
});

because imgui pulls in emscripten, which means we don’t have the ability to call instantiateStreaming.

With emscripten, declaring an external function is easy enough.

extern fn jsLog(ptr: [*]const u8, len: usize) void;

There are a couple of options to wire them up to the javascript:

`library.js` / `mergeInto`

This option requires javascript files on the zig side. If you want to start with typescript, you’ll need to integrate a transpiler into the build chain as well.

First, you want a javascript file - let’s call it libshine.js, and pop it into a js dir.

// js/libshine.js
// Emscripten will provide these globals at link/runtime
declare var mergeInto: (lib: any, funcs: Record<string, Function>) => void;
declare var LibraryManager: { library: any };
declare function UTF8ToString(ptr: number, len?: number): string;
mergeInto(LibraryManager.library, {
jsLog: (ptr: number) => {
const msg = UTF8ToString(ptr);
console.log("🟢 Zig says:", msg);
},
});

We then need to pass this js file into the build step

as part of my sokol build step, I pass it in as .extra_args.

// create a build step which invokes the Emscripten linker
const link_step = try sokol.emLinkStep(b, .{
.lib_main = shine,
.target = opts.mod_main.resolved_target.?,
.optimize = opts.mod_main.optimize.?,
.emsdk = dep_emsdk,
.use_webgl2 = true,
.use_emmalloc = true,
.use_filesystem = false,
.shell_file_path = opts.dep_sokol.path("src/sokol/web/shell.html"),
// set the js file here
.extra_args = &.{
"--js-library", "js/libshine.js",
},
});

We can then call it from zig, with something like:

pub fn main() void {
jsLog("hello from zig");
}
extern fn jsLog(ptr: [*]const u8) void;

From my firefox console:

Lume live reloading is ready. Listening for changes...     localhost:3000:102:15
🟢 Zig says: hello from zig                                shine.js:3168:11

`EM_JS` / `EM_ASM`

The other option is to use EM_JS which involves writing a wee bit of C, which can embed the javascript.

In theory, it’s as simple as:

#include 
<emscripten.h>
EM_JS_DEPS(bla, "$UTF8ToString");
EM_JS(void, jsLog, (const char* s), {
console.log(UTF8ToString(s));
});

and adding it into the build file:

// build the main file into a library, this is because the WASM 'exe'
// needs to be linked in a separate build step with the Emscripten linker
const shine = b.addLibrary(.{
.name = "shine",
.root_module = opts.mod_main,
});
// get the Emscripten SDK dependency from the sokol dependency
const dep_emsdk = opts.dep_sokol.builder.dependency("emsdk", .{});
// need to inject the Emscripten system header include path into
// the cimgui C library otherwise the C/C++ code won't find
// C stdlib headers
const emsdk_incl_path = dep_emsdk.path("upstream/emscripten/cache/sysroot/include");
shine.root_module.addCSourceFile(.{
.file = b.path("src/libjs.c"),
.flags = &.{}, // optional extra emcc flags
});
shine.addSystemIncludePath(emsdk_incl_path);

The calling code in main.zig remains the same:

pub fn main() void {
jsLog("hello from zig");
}
extern fn jsLog(ptr: [*]const u8) void;

However, this didn’t work, and failed with:

error: undefined symbol: jsLog (referenced by root reference (e.g. compiled C/C++ code))
warning: To disable errors for undefined symbols use `-sERROR_ON_UNDEFINED_SYMBOLS=0`
warning: _jsLog may need to be added to EXPORTED_FUNCTIONS if it arrives from a system library
Error: Aborting compilation due to previous errors

Thanks to some help from flooh (who btw put together the sokol and sokol-zig packages as well the sokol-imgui-sample template which I used to kick start this project.), I was able to get it working.

Turns out the c file needs to have a function in it that is used in the zig file - it doesn’t need to do anything.

So, based on the suggestion, libjs.c changes to:

#include 
<emscripten.h>
EM_JS_DEPS(bla, "$UTF8ToString");
EM_JS(void, jsLog, (const char* s), {
console.log(UTF8ToString(s));
});
void dummy(void) {};

and in main.zig:

pub fn main() void {
dummy();
jsLog("hello from zig");
}
extern fn jsLog(ptr: [*]const u8) void;
extern fn dummy() void;

From my firefox console:

Lume live reloading is ready. Listening for changes...     localhost:3000:102:15
🟢 Zig says: hello from zig                                shine.js:3168:11

You can see a working example in [my forked repo](

`EM_JS` directly through `zig` [unsuccessful]

Looking at the macro for EM_JS and with my good friend ChatGPT, I attempted translating it to zig and made some progress, but ultimately failed to get it working. I’ll leave the work here in the hopes it might be helpful.

#define _EM_JS(ret, c_name, js_name, params, code)                             \
_EM_BEGIN_CDECL                                                              \
ret c_name params EM_IMPORT(js_name);                                        \
__attribute__((visibility("hidden")))                                        \
void* __em_js_ref_##c_name = (void*)&c_name;                                 \
EMSCRIPTEN_KEEPALIVE                                                         \
__attribute__((section("em_js"), aligned(1))) char __em_js__##js_name[] =    \
#params "
<::>
" code;                                                       \
_EM_END_CDECL

The above macro translates to zig roughly (with help from ChatGPT) as:

extern fn jsLog(ptr: [*]const u8) void;
/// 2. Keep a reference to avoid the linker removing the function.
///    Same role as __em_js_ref_* in the C macro.
pub export const __em_js_ref_jsLog = &jsLog;
/// 3. Embed the JS implementation in a special section called "em_js".
///    Emscripten will scan this and inject the code into the output JS.
export const __em_js__jsLog align(1) linksection("em_js") =
"(const char* s)
<::>
{ console.log(UTF8ToString(s)); }\x00";
pub export fn dummy() void {}

I added a pub fn and called it from main:

pub fn log(ptr: [*]const u8) void {
jsLog(ptr);
}

Which gave me the familiar error about not being able to find jsLog.

comparing the linker sections gave some clues:

❯ wasm-objdump --section=linking -x <path/to/libjs.o>
libjs.o:        file format wasm 0x1
Section Details:
Custom:
- name: "linking"
- symbol table [count=9]
- 0: F 
<dummy>
func=1 [ binding=global vis=hidden ]
- 1: D 
<__em_js_ref_jsLog>
segment=0 offset=0 size=4 [ binding=global vis=hidden ]
- 2: F 
<jsLog>
func=0 [ undefined explicit_name binding=global vis=default ]
- 3: D 
<__em_js__jsLog>
segment=1 offset=0 size=53 [ exported no_strip binding=global vis=hidden ]
- 4: S <.debug_abbrev> section=7 [ binding=local vis=default ]
- 5: G 
<env.__stack_pointer>
global=0 [ undefined binding=global vis=default ]
- 6: S <.debug_str> section=9 [ binding=local vis=default ]
- 7: T 
<env.__indirect_function_table>
table=0 [ undefined exported no_strip binding=global vis=default ]
- 8: S <.debug_line> section=10 [ binding=local vis=default ]
- segment info [count=2]
- 0: .data.__em_js_ref_jsLog p2align=2 [ ]
- 1: em_js p2align=0 [ RETAIN ]

and the zig object:

❯ wasm-objdump --section=linking -x js.o
js.o:   file format wasm 0x1
Section Details:
Custom:
- name: "linking"
- symbol table [count=6]
- 0: F 
<dummy>
func=1 [ binding=global vis=default ]
- 1: D 
<__em_js_ref_jsLog>
segment=0 offset=0 size=4 [ binding=global vis=default ]
- 2: F 
<jsLog>
func=0 [ undefined explicit_name binding=global vis=default ]
- 3: D 
<__em_js__jsLog>
segment=1 offset=0 size=4 [ binding=global vis=default ]
- 4: D 
<__anon_946>
segment=2 offset=0 size=54 [ binding=local vis=default ]
- 5: T 
<env.__indirect_function_table>
table=0 [ undefined exported no_strip binding=global vis=default ]
- segment info [count=3]
- 0: .rodata.__em_js_ref_jsLog p2align=2 [ ]
- 1: em_js p2align=0 [ ]
- 2: .rodata.__anon_946 p2align=0 [ ]`

From what I could understand (which is little), it looks like __em_js__jsLog in the zig obj is a pointer while from C, it’s the full string.

hardcoding it as a static array helped:

export const __em_js__jsLog align(1) linksection("em_js") = [_]u8{
'(', 'c','o','n','s','t',' ','c','h','a','r','*',' ','s',')',
'<',':',':','>','{',' ',
'c','o','n','s','o','l','e','.','l','o','g','(',
'U','T','F','8','T','o','S','t','r','i','n','g','(',
's',')',')',';',' ','}','\x00',
};

The output from this is a little more promising

❯ wasm-objdump --section=linking -x js.o
js.o:   file format wasm 0x1
Section Details:
Custom:
- name: "linking"
- symbol table [count=5]
- 0: F 
<dummy>
func=1 [ binding=global vis=default ]
- 1: D 
<__em_js_ref_jsLog>
segment=0 offset=0 size=4 [ binding=global vis=default ]
- 2: F 
<jsLog>
func=0 [ undefined explicit_name binding=global vis=default ]
- 3: D 
<__em_js__jsLog>
segment=1 offset=0 size=53 [ binding=global vis=default ]
- 4: T 
<env.__indirect_function_table>
table=0 [ undefined exported no_strip binding=global vis=default ]
- segment info [count=2]
- 0: .rodata.__em_js_ref_jsLog p2align=2 [ ]
- 1: em_js p2align=0 [ ]

Let’s look at the two side by side

# From C
- 3: D 
<__em_js__jsLog>
segment=1 offset=0 size=53 [ exported no_strip binding=global vis=hidden ]
# From zig
- 3: D 
<__em_js__jsLog>
segment=1 offset=0 size=53 [ binding=global vis=default ]

There are some clear differences in how the two are output and I am already beyond my knowledge level here - so I’ll leave it to someone who knows this stuff better (or wait until I do)

You can check out the code in the branch of my forked repo

Next steps

My plan is to use EM_JS through C to implement glue JavaScript functions - something like:

EM_JS(void, jsLog, (const char* s), {
Module.jsLog(UTF8ToString(s));
});

By doing this, I can have one-line js code in the .c file and all the implementation can go into the web side (and can easily be TypeScript too).

window.Module = {
jsLog: function (msg) {
console.log("🟢 Zig says:", msg);
},
};

Auto reload WASM with zig+lume

Shri — Wed, 17 Sep 2025 11:20:51 +0000

I’ve been taking some time off to rest and recover from health issues that made
it hard to focus. To ease back in, I’ve started a small project:
shine

The project would do well to be multiplatform - mobile and web. The obvious
choice was flutter and I have enjoyed working with it before.

However, as I'm currently in love with zig, I wanted to work with
that instead.

Libraries

Graphics

I've been playing with raylib and that was my initial instinct.
However, raylib
does not support iOs and
has issues with wasm

I considered a few options, including

sdl, which looked great but was perhaps a little too low level for me.
jok - does not support mobile and possibly has a little more than I needed.

In the end, I decided to go with sokol and
sokol-zig.

While a little more lower level than raylib, it has:

a modern clean api
first class mobile support
first class wasm support

UI

I've been working with dvui a lot recently. Unfortunately, it
doesn't support sokol. imgui is a better
option.

There is even a
template project that I could start from.

WASM first

To keep things straightforward, I decided to start with wasm. If I make the site
mobile friendly, I could see how it goes and see if it needs a mobile version.

I will need some shared data storage and have been considering
supabase, which has javascript
libs. By using wasm, I can effectively shim in js functions to
handle that instead of having to write bare rest calls from zig.

Structuring the project

Is this a zig project with a web component, vice versa or indeed two independent
parts that work together.

I did a fair amount of web searching to see if there was some guidance I could I
find for a good way to structure a relatively straightforward zig+js project.

I could not find one. In the end, I decided to keep it fairly straightforward.

- shine/
  - src/ # zig code
  - web/ # all the web stuff

Frontend

After a bit of research, and realising that I will probably need a little bit of
supporting content around shine, I decided to go
with lume

I used the simple-blog theme as
a template to start from. I could have just pulled the template in but I wanted
a custom homepage.

When I tried to add an index.md, it complained about two files wanting to
write index.html. From what I could find, the easiest way to override the
homepage was to just pick up the theme and edit it - which was easy enough.

WASM => frontend

I didn't want to copy over the wasm and the js file every time, so I added a
couple of steps to build.zig right after the link_step (also included below)

// build.zig
// create a build step which invokes the Emscripten linker
const link_step = try sokol.emLinkStep(b, .{
    .lib_main = shine,
    .target = opts.mod_main.resolved_target.?,
    .optimize = opts.mod_main.optimize.?,
    .emsdk = dep_emsdk,
    .use_webgl2 = true,
    .use_emmalloc = true,
    .use_filesystem = false,
    .shell_file_path = opts.dep_sokol.path("src/sokol/web/shell.html"),
});
// attach to default target
b.getInstallStep().dependOn(&link_step.step);

// Copy shine.js from default emscripten output
const js_install = b.addInstallFileWithDir(
    b.path("zig-out/web/shine.js"),
    .{ .custom = "../web/src/static/shine" },
    "shine.js",
);
js_install.step.dependOn(&link_step.step);
b.getInstallStep().dependOn(&js_install.step);

// Copy shine.wasm from default emscripten output
const wasm_install = b.addInstallFileWithDir(
    b.path("zig-out/web/shine.wasm"),
    .{ .custom = "../web/src/static/shine" },
    "shine.wasm",
);
wasm_install.step.dependOn(&link_step.step);

These steps will copy across the wasm and the js file across to static/shine.
I wanted to put the js in src/js and the wasm in the static dir. However, the
js file expects the wasm in the same dir. I tried overriding locateFile but it
didn't work.

<!-- index.vto -->
<script>
  window.Module = {
    locateFile: (path, prefix) => {
      if (path.endsWith(".wasm")) {
        return "/static/shine/shine.wasm";
      }
      return prefix + path;
    },
  };
</script>
<script src="/js/shine.js"></script>

I was able to get lume to process the javascript file by adding it.

// _config.ts
site.add("static/shine/shine.js");

Conclusion

With all of these set up, I was able to run:

zig build -Dtarget=wasm32-emscripten --watch

in one window. This command will rebuild wasm and provide it to lume whenever
the zig code changes.

deno task serve

Running this in another window will mean that lume will rebuild on any changes,
including a new wasm file and redeploy. The redeploy will trigger an auto-reload
of the page as well if I have it in a browser.

I now effectively have automated reload with changes if I make changes in either
zig or the frontend.

I don't have hot reload - but this is pretty good for now.

Building Pong in Zig with Raylib – Part 1: Setup, Paddles, and Ball

Shri — Sat, 28 Jun 2025 19:38:29 +0000

Before continuing development on Triangle - my larger, arcade ARPG, factory game, I wanted to take a step back and build something small and familiar. Pong felt like the perfect choice: quick to prototype, easy to understand, and a good warm-up before diving deeper into raylib again.

This post goes alongside my video on YouTube , and walks through the early steps of the project: setting up the game, getting something on screen, and implementing the paddles and the ball.

Why Pong?

Sometimes, before getting deeper into a project, it helps to do something simple just to get your hands moving again. I hadn’t written Zig in a couple of weeks, and wanted a fast feedback loop to:

Get back into using raylib-zig
Have a bit of fun
Remind myself why I made certain decisions in the first place

Project Setup

I’m using raylib-zig for this. You can scaffold a new project with:

./project_setup.sh <project-name>

You could also use zig init and then add the dependency in manually if you prefer.

Drawing the Playground

The Pong “arena” is simple:

Two paddles
A ball (currently static)
A center dividing line
Placeholder for scores

Implementing Paddles

The paddles have:

A position (top-left corner)
A fixed size
A simple render function

const std = @import("std");
const rl = @import("raylib");

const Paddle = @This();

pos: rl.Vector2,

pub fn init(x: f32) Paddle {
    return .{ .pos = .{
        .x = x,
        .y = 200,
    } };
}

pub const size = rl.Vector2{ .x = 25, .y = 100 };

pub fn render(self: Paddle) void {
    rl.drawRectangleV(self.pos, size, .white);
}

It might have been nice to be able to have the paddle calculate more of its own values, but the more I think about it, the more it makes sense to keep the logic in paddle simpler.

Ball Placeholder

To wrap things up for this session, I added a static ball in the center of the screen. It has a radius, position, and velocity fields ready to go. Rendering is straightforward:

const std = @import("std");
const rl = @import("raylib");

const Ball = @This();

pos: rl.Vector2,
r: f32 = 16,
vel: rl.Vector2 = .{ .x = 0, .y = 0 },

pub fn render(self: Ball) void {
    rl.drawCircleV(self.pos, self.r, .white);
}

What’s Next

This was mostly about warming up, but the next episode will tackle:

Adding velocity to the ball
Basic collision detection with paddles

I’ll try and think about simplifying paddle logic, especially the awkward symmetry between left and right.

You can find the full source code on GitHub .

See you in part 2!

DEV Community: Shri

Mobile Strategy Games Don't Have a Monetisation Problem - They Have a Game Problem

Monetisation as Design

Just out of reach

Spend, spend, spend

Social Pressure

In-game currency vs real money

Buying Ego

Events Funnel To Spend

Why it works

Well, let’s make it ethical

Good Live Service Games

The Fundamentals

Player Value

What I’m Left With

Sovereignty Over Convenience

Tooling & Services

Cloud IaC

Bare Metal IaC

Cloud Services

Backup

Monitoring

Migrating

atlas

Base Config

Scaleway

Deploying the websites

Monitoring & Alerting

Journey So Far

Next Steps

Conclusion

Only One Per Customer

Allow multiple connections

Reject additional connections

Close existing connection on reconnect

Always On

Did They Have a Problem That Year?

What we Carried

Whatcha Thinking?

Publishing from hugo to dev.to

Goals

Pre-existing Solutions

Using Hugo

Limitations

Define a new content type

Render code blocks as markdown

Render absolute urls

Output

Next Steps

Images

Tags

Automation

Conclusion

Using `locateFile` to have js and wasm in different locations with emscripten

Include emscripten js file

Override Module

Closing

Calling Javascript from Zig through WebAssembly

Goals

Options

library.js / mergeInto

EM_JS / EM_ASM

EM_JS directly through zig [unsuccessful]

Next steps

Auto reload WASM with zig+lume

Libraries

Graphics

UI

WASM first

Structuring the project

Frontend

WASM => frontend

Conclusion

Building Pong in Zig with Raylib – Part 1: Setup, Paddles, and Ball

Why Pong?

Project Setup

Drawing the Playground

Implementing Paddles

Ball Placeholder

What’s Next

Override `Module`

`library.js` / `mergeInto`

`EM_JS` / `EM_ASM`

`EM_JS` directly through `zig` [unsuccessful]