Fastify hosting
on Shipped.
Bring your Fastify API and its plugins to production. Keep your route schemas and application structure while Shipped runs the service.
Keep routes and plugins together
Fastify applications organize behavior through routes, hooks, and plugins. Package that application with its dependencies and production start command, then deploy it as a web service. Shipped handles the domain and HTTPS around your server without changing how your plugins register their behavior.
Connect shared resources deliberately
Database connections, cache clients, and integration settings can sit behind your Fastify plugins. Supply their values through secrets and connect the app to PostgreSQL or Redis as needed. Use separate environment settings so a staging API cannot accidentally write to the same resources as production.
Make API releases easy to inspect
Use staging to check request validation, response formats, and authentication hooks against the clients that depend on them. Service logs help trace a failed request to application behavior. When a release needs to be replaced, deployment history lets you restore an earlier app while you investigate.
A little more detail
Questions about Fastify?
Does Shipped change my Fastify schemas or plugins?
No. They remain part of your application. Build and deploy the plugin set your project requires, and test its route behavior in staging.
Can I use Fastify for a worker too?
A background worker normally runs a separate job-processing entry point rather than listening for HTTP requests. It can share application modules with your Fastify service and use the same supporting database or queue.
From your workspace to the web