Migrating this site to BunnyCDN

4 min read

Ever since the orange man got elected for the second time, I’ve been telling everyone that Europe needs to be more independent and strip itself of its dependence of software exports from the US. The Americans are no longer to be trusted: we do not wanna end up in a situation where we get rug pulled. Which btw has already occured, the export restrictions on Fable 5 is just the latest, viral example.

And yet I am hosting my own page on Cloudflare, an American company, listed on the NYSE, owned by Americans who are permeating and centralizing the web in a way that the founding fathers of the web are disagreeing with [1]. Also, as a side note, Cloudflare has severe problems serving content to most Germans due to (missing) peering agreements with Deutsche Telekom AG, causing for most Germans traffic to be routed through congested internet exchange points [2]. In this case, Cloudflare is not to be blamed but the matter of fact exists that my site is really slow for most Germans during the weekend and evenings.

Another reason why I am unhappy with Cloudflare is that their proprietary Ecosystem, like Workers/D1/Auth entrench my site into their ecosystem. I want my site to be easily plugable into whatever static site host you could think of, but at the same time with a global delivery network, as I have quite a few visitors from south-east Asia. One more nit: Cloudflare pages is incompatible with Forgejo which forces me to mirror my site to Github just to trigger the action there. Granted, their eco system is easy to use, well documented, free for many users (until they rug pull you), its reasonably fast. Overall, a very appealing package.

The new architecture 🇪🇺

… is based on a dead-simple static site and BunnyCDN, a Slovenian 🇸🇮 company.

Together with Claude, it took about an hour to do the full migration, including a few larger refactorings that were required to make the site fully static. Rough order of execution:

  1. Delete the /admin endpoint that was previously protected by Cloudflare Access
  2. Migrate the CV Verification tool:
  3. Migrate to the Astro static adapter
  4. Provision resources on Bunny
  5. Setup a deploy script
  6. Setup CI to run the deploy script on push

CV Verification tool migration

It used query parameters to dynamically load data from Cloudflare D1, neither is transferable in this way to BunnyCDN. For once, query parameters are not compatible with a fully static site -> hence, we migrate the urls to /cvv/<id> from /cv?id=<id>. All entries that were previously stored in the D1 database I migrated to a local, new Astro collection called cv-verify. An Entry looks like that:

company_name: "A new Test Company"
author: "Alexander Daichendt"
purpose: "Website Demonstration"
tooling: "Typst"
created: 2025-01-03T08:41:12.488Z
status: "active"
sha256: "04c40a63f3cd6fdfa551b3ead7a9cb7d861c3062f5b6f3416e72e0bec991af7a"
pgp_signature: |
  -----BEGIN PGP SIGNATURE-----

  iQIzBAABCAAdFiEEzxEBUi7HUZS2aKmFBCRLpnBlzJAFAmd3orsACgkQBCRLpnBl
  zJA5mA//WlTeC6RojgfpyFjEF1IuTy+elUFI2JJqCaZbN4eNwWAdLXoRmprzoS3A
  IRkl1rQ5LddMlse9/b7mm8UaEWgxyPFoChPxEywa0ptFKY8X+EJR2jEXiwUJ9JNZ
  +eCzc2nNe/2T9L18sc/UZVLqdSgrhehgc33i0r+rRMBgVYNgXfnmiopzGWF+hx9K
  dfbkiRTfAeNUv0caQ2E5Z8GSGtOPaVNOb/bTdEJ/E9714EWiCdvHR06pz33drtKB
  9x/TOl/xd4OO8IMtq0xzkPay5COAlBqxzvRvFdZ20qYZCMtnDwS7XxY3lirBSWW9
  JpjQX64V64OtVHc8/Pjox/SoF20dS4kqb9ZMLj6c3fsRQrydGllRZ9zWg2bLwfYZ
  2uj9ptTIHlNny7BN925g0Qn4asCDgxyZzUhenQx/4jkDckOd1DjKEtQ8ndqyLw2G
  6v8AQTQ+nkVIbpN7OdCWoC1kEWiBfiE4rczkmf+6A2SVWaBjB/r+Umi3jG4m5+TV
  l6AzD8nP22SRqsPFyc+POodIlyqhHr/3ukUfgc4Z5f4bQHwvw4WniWkBxuaMmwzR
  2u3ymjK79Suls1Fb9sh15ctbLms8Z2y9VQ9VhuduXq7KRYDteGR0ye0389UEn+nS
  UDzEa5BOlmL6Us6zGFkiyLeVi3sLm/djJ/1pymssmY7n1i8u3DI=
  =fHLJ
  -----END PGP SIGNATURE-----

So its all local now, and for each of these yamls, a separate static page is generated. In principle, people could enumerate all possible IDs now to find out who I applied for. To counter that, I setup rate limits.

Resources on BunnyCDN

There’s an equivalent to an S3 Bucket, they call it a Storage Zone. I upload the output of the Astro (the dist/) folder to that bucket - Claude was helpful enough to create a dependency-free deploy script that diffs the output against whats already uploaded and upload/delete through HTTP requests. I’ve setup replication into all zones, for my current site that costs about 5.5 cents per month. A no brainer.

The other resource is a so called “Pull Zone”, the Cloudfront counterpart that’s distributing our content. I add my daichendt.one domain there, change the CNAME entry to whatever URL they provide me with and enable a SSL cert. We are all set!

Automatic deployments

I’ve now got a Forgejo runner on my Unraid server who will automatically pick up on push the code, build it, and execute the deploy script.

Conclusion

I thought about doing this for over a year now. I even created my Bunny Account last year in July and put 10 Euros on it, but then got discouraged actually migrating there as there was no replacement yet for Workers/D1 and back then I didn’t have the foresight to make it completely static. Super glad this is finally sorted out.

Btw, Astro 7 is crazy fast. The power of 🦀

  1. https://broadbandbreakfast.com/the-internet-dispersed-power-the-supreme-court-is-concentrating-it/
  2. https://netzbremse.de/