• Accepted Date: 2026-04-16
• Reference Issues/Discussions: Advanced Routing #1320
• Author: @matthewp
• Champion(s): @matthewp
• Implementation PR:

Summary

This proposal introduces optional src/app.ts support as Astro's request entrypoint, giving users full control over the request pipeline using a standard fetch-based API. Astro's rendering and features are composed within this entrypoint. A Hono app can also be exported directly since it shares the same { fetch } shape, and Hono middleware support is provided as an add-on.

Background & Motivation

Today, Astro controls the entire request pipeline internally. Users can hook into it with middleware, but they can't control when things run relative to each other or relative to Astro itself. In practice this means:

• No explicit request ordering. If you need auth to run before Astro rendering, and logging to run after, you're relying on implicit middleware ordering that Astro controls. There's no way to say "run this, then Astro, then that."
• Features are tightly coupled to Astro internals. Middleware, Actions, rewrites, and i18n are all baked into Astro's request handling. They can't be used independently, reordered, or replaced — they run when and how Astro decides.
• Hard to integrate non-Astro request logic. If you want to mount an API from another library, add rate limiting, or run platform-specific logic before Astro sees the request, you're working against the framework rather than with it.

src/app.ts gives users an explicit entrypoint where they control the full request lifecycle. Astro features like Actions or redirects can be extracted into standalone packages that users compose themselves.

Goals

• Introduce optional src/app.ts as a first-class request entrypoint.
• Use a standard fetch-based API as the contract, allowing users to control the request pipeline with plain Request/Response objects. Since a Hono app exposes the same { fetch } shape, exporting a Hono app works naturally.
• Provide Hono middleware as an add-on (astro/hono) for users who want to use Astro features within a Hono middleware chain.
• Keep current behavior unchanged when src/app.ts is not present.
• Move existing Astro request features like Astro middleware, rewrites, Actions, into entrypoint modules (astro/rewrites for example) src/app.ts.

Non-Goals

• Replacing Astro's adapters with third-party framework adapters. This could be a long-term goal to make Astro more maintainable but is a lot more work than the src/app.ts idea discussed here.

Open questions

• How should state be shared across Astro features in src/app.ts? Options include a mutable state object (like AstroRequest above), storing state on the request object, or something else.
• How does src/app.ts interact with platform-specific entrypoints like Cloudflare's worker.ts?
• How do integrations that currently inject middleware participate in this model?