Devlog 6

Continuing x44 after 2 months. I was very busy with school work.

Coming back to it after a long time, i am seeing that my initial design had the Rust build worker doing too much. The CF Worker pushed a job to a queue and sent a ping to the VPS over HTTP. The Rust build worker then had to authenticate against CF’s REST API, pull the queue message, execute the build, upload artifacts to R2, and acknowledge the message. This over complicated the system.

The Architectural Change

Instead of the rust build worker pulling jobs queues after the ping, I made the control-plane worker both queue producer and queue consumer.

Now the Pipeline Looks like this:-

1. When a project is created or a git push occurs the Worker records a queued row in D1 and pushes the build configuration into the queue.
2. The Worker then takes 1 job from the queue and send the build configuration to the Rust build worker, If a build is running CF natively waits for it to be acknowledged-no custom logic for it
3. Then the Rust build worker finally runs the build and upload the build output to R2.[I acknowledge the job even if the build fails to prevent retry loops]

No frontend changes, see my IDE

Finally made my personal website.
The doodles are also made my me :)

PS: the ring glow is not intentional, i was just bluring the background. but i like how it looks :P

If you want the background: https://moewalls.com/abstract/the-crown-of-thorns-live-wallpaper/

Devlog 5

I finished the /new-project page and wrote some types.

While testing I found a major bug, that if a build request comes to the build-worker while a build is running then the output files gets overwritten, resulting in a broken deployment. I could fix it by having the outputs of the build on separate folders and uploading them one by one. But this approach wasn’t utilising the queues.

I will change the structure to something like this, [Github Webhook/Initial Deploy] -> [Control-plane] -> [Cloudflare Queue] -> [control-plane queue handler] -> this sends the build details to the build-worker after building it will update the status of the deployment. This was i don’t have to manage concurrency my self

I am spending a lot of time in styling. hope it looks good :?)

Nexxt

1. Building what I just explained.
2. Improve the bland dashboard.

Devlog 4 - Build the structure of the dashboard

Just build the layout of the dashboard and created a new page for creating new projects[design inspired by cloudflare].

You might be thinking that this should not take 10 hours and you are right. My first thought was to not to create a new page but a dialog box. But the combobox I used for selecting repo was not registering the clicks, i was working with keyboard tho. After trying to debug a lot, I asked AI why it was not working as intended. Because I had both base-ui and radix-ui wasted 4 hours on it and ended up creating a new page altogether

Next:

• Complete the /new-project page
• Connect the builder with the backend
• Add a detail page for projects

Devlog #3

Changes

1. Made the landing page for x44. Tho it was mostly generated by AI, I did the authentication and styling for the button.
2. Set-up drizzle orm and wrote the schema for the database.
3. Authentication(used better-auth)

The problems I faced

1. I tried to make my own authentication system, and realised after more than two hours of work that there is still a lot of work to be done to make it secure. And i can use that time to add more features. So I switched to better-auth it was a great decision according to me. And if you are in search of an authentication framework I recommend you to check better-auth once them have amazing documentation.
2. To initialise better-auth in cf worker, I first needed to initialse drizzle and it requires a D1 instance which in only available in the context of a request. So I made a getAuth function

const getAuth = (ctx:Context) => {
  const db = drizzle(ctx.env.DB, {schema})
  const auth = betterAuth({database:drizzleAdapter(db, {provider:"sqlite",schema})})
  return auth
}

Currently working on dashboard(this is not by AI)

If you have any suggestion please comment, and you can view the system architecture in the previous devlog[i am not yet sure about the subdomain routing part, so that is not drawn]. ✌️

This commit was a big one. The build-worker finally got a proper API layer, added Axum with an auth middleware so only authorized clients can trigger builds. The whole flow is now queue-driven: the worker pulls jobs from Cloudflare Queues, runs the Docker build, uploads output to R2, and acknowledges the message. Feels way more production ready.

Also spun up the monorepo structure properly. Added apps/control-plane (Cloudflare Worker), apps/website (Vite frontend), and packages/db-schema for shared types. pnpm workspaces are configured, root package.json has a dev:backend script. Basic .gitignore in place.

The most frustrating thing was that the Cloudflare Queue send function is not working. I’ve spent hours trying to debug it, messages aren’t showing up on the CF dashboard at all. The pull/ack endpoints seem fine, but pushing messages into the queue is a dead end. Hoping that actually deploying the control-plane worker might fix it,maybe it’s a local dev environment issue with wrangler. Either way, this is the main blocker right now. If anyone has hit this, I’d love to hear how you solved it.

Git commit: https://github.com/xxeisenberg/x44/commit/9b1669bd7e935043367ba32c2abadc1428f80596

I have built the docker image that will build the code and a rust program that will run the docker container and upload the build output to Cloudflare R2.

Finished the bot!

Just hosted my first slack bot on nest! I am planning to add other slash commands