Roadmap

This page tracks the larger initiatives in flight or on the horizon. Smaller fixes and incremental improvements happen continuously and don't get individual entries here - they're in Release Notes when they ship.

Reepolee ships when things are ready, not on a fixed schedule. Items below are organised by horizon (next release, this year, longer term) rather than by date. An item moving from "longer term" to "next release" is the most reliable signal that work has actually started.

Next Release

Items being worked on for the next monthly release.

Native Bun SMTP client

The current lib/smtp.ts is built on Bun's Node compatibility layer (node:net and node:tls). When Bun adds a native SMTP client to its standard library, we'll reassess the implementation. See Sending Email.

Automatic view routing as the default

The CRUD generator already detects SQL views and emits sql_view.ts for view-backed lists (v_frameworks joining frameworks, developers, and languages). The remaining piece is making the table.ts select_table view override the default for list pages instead of a manual per-route choice.

This Year (2026)

Documentation expansion

This documentation site is at first-pass coverage. The next pass focuses on:

  • Cookbook recipes for more advanced patterns: search-as-you-type, file-based attachments, multi-tenant isolation, scheduled jobs, integrating with external auth providers.
  • A "From SvelteKit / Laravel / Rails" comparison page for each major server-side framework, showing the equivalent Reepolee pattern for common idioms.

A test suite for the framework code

Reepolee ships with bun test available but doesn't currently have comprehensive coverage of the framework itself. The plan: a test suite for lib/ modules (template engine, render layer, middleware, helpers) that runs in CI on every commit. Application-level testing patterns will get their own recipe.

A reepolee new <project> CLI

Starting a project already ships as bun create reepolee/reepolee my-app - it fetches the starter tarball, initializes a fresh repository, and runs the installer. A dedicated reepolee new command (fetching the latest tagged release into any folder name) would build on that once the release packaging is settled.

Longer Term

Items that are real ambitions but not actively in flight.

Background jobs and scheduled work

Many projects need either "run this every N minutes" or "queue this to run later." Reepolee doesn't currently provide either; the workaround is a small worker process that polls a pending_jobs table or uses Bun's setInterval. We're considering a built-in lightweight job runner that uses the existing database-backed queue pattern with no additional infrastructure. The decision is whether the scope is worth the surface area it adds.

A managed Reepolee host

The framework targets self-hosted deployments. A managed option - push to a branch, deployment happens, TLS/scaling/backups handled - would lower the floor for projects that don't want to operate a server. This is more of a Reepolee product question than a framework question; the framework would stay deployable on any Linux box regardless.

Real-time features

WebSocket plumbing is built into Bun and has been used in Reepolee's dev-mode live-reload. Productising it as an application-level pattern (rooms, broadcast, presence) is a real opportunity but a sizeable surface area. The current direction is to wait until enough applications need it that the right shape becomes obvious, rather than designing a system in advance and hoping it fits.

Not on the Roadmap

A few things we don't currently plan to add - not because they're bad ideas, but because they conflict with what Reepolee is:

  • A separate ORM layer. Bun's SQL API is the abstraction; queries are SQL. An ORM is a different framework with different trade-offs.
  • A client-side router. Reepolee stays server-rendered and uses normal document navigation. Applications that need a true single-page-app experience should use a dedicated SPA framework.
  • A built-in component library. The shipped components/ set covers form inputs and the banner. Extending into navigation components, modals, data tables, etc., expands the project's surface in a direction we've deliberately stayed narrow on. Build them in your project - they're yours, and they fit your visual language.
  • Plugin system / extensions. Reepolee's extension model is "edit the file." Adding plugin hooks adds API surface that has to stay stable; "edit the file" stays flexible forever.

Influencing the Roadmap

The single most useful input we get is "I tried to do X and it was awkward in this specific way." Concrete pain - a use case that didn't fit - is what moves items up the priority list. Abstract feature requests ("Reepolee should support X") are harder to act on without that context.

The forum for this is GitHub Discussions. Tag a thread with roadmap if it relates to something on this page; start a new discussion if it's a fresh idea.

For sponsors, the relationship is more direct - sponsorship doesn't buy roadmap influence per se, but it does buy a regular conversation about what you're building and where it's friction-y. See Sponsors.