Bun hosting
on Shipped.
Keep Bun in your production stack. Ship the app and its runtime together, with Shipped handling the infrastructure that serves it.
Make the runtime part of the release
Bun can be your package manager, build tool, runtime, or a combination of those roles. Define which commands build the project and which start the production service. A container gives you a clear way to package the Bun runtime and any system dependencies your application relies on.
Connect a small service to real data
Start with a Bun HTTP service and add PostgreSQL or Redis as the app needs them. Store connection settings as secrets and keep test services separate from production. When tasks grow beyond a single request, run a worker or scheduled job with its own entry point.
Ship from the same development workflow
Your coding agent can send the local project to Shipped through MCP. GitHub deployment is also available when changes should follow repository history. Review the built service in staging and use logs to check startup, package loading, and incoming requests before making it the production release.
A little more detail
Questions about Bun?
Does using Bun to install packages mean my app runs on Bun?
No. The install, build, and production start commands determine those choices separately. An app can use Bun for tooling while running under Node.js, or use Bun for both.
Will every Node.js package work unchanged on Bun?
Compatibility depends on the package and runtime APIs it uses. Test your dependency set with Bun and package the runtime you have validated; hosting does not remove those compatibility differences.
From your workspace to the web