The first half of my GSoC work has been less about one single feature and more about a bigger transformation inside the BLT ecosystem.
The main direction is simple: move BLT products away from the older Django-style setup and reshape them into smaller, faster, Cloudflare Worker-based apps. Instead of one heavy backend trying to do everything, each product can now have its own focused frontend, Worker API, D1 database, authentication flow, and deployment path.
That sounds like infrastructure work, but it has been very product-focused too. The goal is not just to migrate code. The goal is to make BLT easier to maintain, easier to contribute to, and easier to run as a set of modern open source tools.
What changed so far
A lot of the work has been around splitting the BLT ecosystem into cleaner product areas and giving each one a better direction.
BLT Design
BLT Design became the visual base for the ecosystem. I worked on making the design direction cleaner and more reusable, so other BLT products can follow the same style instead of each repository inventing its own UI.
This includes shared patterns for:
- Colors
- Cards
- Buttons
- Page layouts
- Dark mode
- Product page templates
BLT Docs
BLT Docs is being turned into the main documentation hub for BLT. The work here is about making the documentation feel organized, useful, and contributor-friendly.
Instead of scattered README-style content, the goal is to have proper platform documentation, including:
- Setup guides
- Repository maps
- Contributor paths
- Architecture notes
- Deployment documentation
BLT API and Auth
BLT API is one of the most important parts of the migration.
The API direction is now Cloudflare-first, with /v2 routes, D1 storage, and a clearer split between API access and user identity.
The existing X-BLT-API-Key gate remains the API authentication layer, while JWT/session authentication becomes the user identity layer.
Authentication is also becoming a shared foundation across BLT products. This matters because products like Jobs, Hackathon, Newsletter, Timer, and Sizzle all need a reliable way to identify users.
BLT Jobs
BLT Jobs is being planned as a lightweight job and contributor platform for the BLT ecosystem.
The direction is to make job listings and contributor opportunities easier to manage without depending on a heavy backend. The Cloudflare Worker approach fits well here because the product can stay simple, fast, and easy to deploy.
BLT Hackathon
BLT Hackathon is being redesigned into a cleaner event and contribution dashboard.
The work includes:
- Better landing pages
- Event dashboards
- GitLab support
- GSoC-ready workflows
- Statistics
- A more polished UI
The goal is to make hackathons and contribution events easier to discover, track, and manage.
BLT Newsletter
BLT Newsletter has moved from a static, GitHub Issues-based workflow toward a real Cloudflare Worker-powered newsletter platform.
Current direction includes:
- D1-backed subscribers
- Admin authentication
- Issue management
- SendGrid email delivery
- Queue-backed campaigns
- Dashboard APIs
This was one of the clearest examples of the migration: taking something simple but limited and turning it into a production-ready product.
BLT Timer
BLT Timer is being shaped into a minimal time-tracking product.
The direction is to:
- Remove GitHub/GitLab OAuth dependency
- Use custom authentication
- Serve static frontend pages
- Use a Python Cloudflare Worker backend
- Store data in D1
The goal is a clean, non-invasive time tracker that fits naturally into the BLT ecosystem.
BLT Sizzle
BLT Sizzle is the daily check-in product.
The idea is that contributors can check in every day with:
- What they worked on
- What they plan to do next
- Whether they are blocked
It is being built around organizations, members, administrators, and approval workflows so it works for real teams instead of only individual users.
BLT CLI
BLT CLI is still ongoing.
This is the part that can tie the ecosystem together from the developer side. Contributors should eventually be able to interact with BLT workflows, setup commands, project tooling, and future automation without needing to understand every repository individually.
The bigger picture
The biggest thing I learned during this first half is that migration is not just about changing the runtime.
Moving from Django to Cloudflare Workers changes how you think about the entire product:
- Keep apps small and focused
- Use D1 where a lightweight database is sufficient
- Keep frontend pages simple and fast
- Avoid overcomplicated backend workflows
- Make deployment easier
- Make every product easier for contributors to understand
This also forced me to think more about consistency. If every BLT product has a different UI, authentication model, documentation structure, and deployment workflow, contributors will get lost.
A significant part of this work has been creating reusable patterns that can be shared across the ecosystem.
What is next
For the second half, the focus is on completing and hardening the ecosystem:
- Complete more Worker/D1 backend integrations
- Polish authentication across products
- Remove remaining Django and GitHub-specific assumptions
- Improve documentation and deployment guides
- Finish more product dashboards
- Continue BLT CLI development
- Make the products feel like one connected BLT platform
Closing thoughts
This first half was largely a foundation-building phase. Many pieces moved at once, but the overall direction is now much clearer.
BLT is gradually becoming a collection of focused, Cloudflare-first products instead of one large monolithic system. That feels like the right direction: faster to ship, easier to maintain, and much better for open source contributors.
Top comments (0)