Backend runtime
Railway services for Renaro operations
Renaro keeps the public landing site static while operational API and worker services run as backend services for dispatch, jobs, payments, and integrations.
- API
- Fastify service
- Worker
- pg-boss jobs
- Landing
- Static Astro app
- Boundaries
- Explicit runtime split
Separate marketing from operations
A public landing page should not carry the runtime complexity of the dispatch app. The API and worker own operational side effects.
- Keep public pages static and crawlable.
- Keep API routes, jobs, payments, and integrations in backend services.
- Document platform boundaries clearly for future deploy work.
Where this page fits
Runtime pages help technical buyers and maintainers understand the split between SEO surfaces and operational services.
- Link runtime content to API, webhooks, and security pages.
- Keep marketing copy consistent with the root platform rules.
- Avoid introducing unsupported infrastructure assumptions.
Related integration paths
Common questions
Are integrations implemented directly in the landing app?
No. The Astro landing app documents and routes SEO traffic to Renaro's product areas. Operational integrations are owned by the API, worker, and platform domains.
Why create integration landing pages?
Operators and technical buyers search for specific provider support. These pages state the current data and workflow boundary and link to capabilities that are available today; they do not imply that an unconfigured OAuth connector is live.
See Renaro with your own trips.
Bring a few of your real reservations. We'll show you how your office would handle them in Renaro, from the first phone call to the paid invoice.