A plain guide to what Jetpacked does, what it handles for you, and what to expect when your project depends on outside services.
Jetpacked is for developers who want to ship without becoming a DevOps engineer. If you have a working GitHub repo and need a live URL, without touching Docker, Nginx, or cloud consoles, Jetpacked is for you. Whether you built it yourself, with a team, or with AI tools, it does not matter. What matters is the code works and you want it online.
No. Jetpacked prepares the server setup, app settings, HTTPS, logs, and database wiring behind the scenes. You still own the app code, but you do not need to learn the hosting machinery just to share a working link.
Jetpacked can refresh the running app from your selected branch automatically, so your updates go from GitHub to the live site without server commands. Enable auto-deploy in your project settings.
Jetpacked does not rewrite your repository. It reads the project, generates the runtime files it needs on the server side, and starts the app from your GitHub code.
Jetpacked is growing fast, but it does not support every ecosystem yet. Today it is strongest with JavaScript and TypeScript web apps: Next.js, Remix, Vite, Astro, Express, NestJS, AdonisJS, and similar frameworks. When Jetpacked cannot confidently prepare a project, it tells you clearly and uses that signal to help us prioritize support for more stacks.
Not yet, but they are directly next on the roadmap. Laravel and Django are exactly the kind of full web apps Jetpacked is built to understand, so support for PHP and Python projects is one of the next big steps.
Jetpacked can run the web app, but the Supabase part still lives at Supabase unless the project has been built to use its own database. That is not a failure. It just means the app depends on an outside service, which is completely normal.
Jetpacked detects which database your project needs from your dependencies and config, then provisions it and wires the runtime environment before your app starts. Migration commands run automatically on every deploy. Supported databases include Postgres, MySQL, MongoDB, and Redis.
Databases are included in every plan. Storage limits are plan-based (512 MB to 50 GB). There is no separate database cost on top of your plan.
Yes. Environment variables can reference managed values such as the public app URL, database details, generated credentials, and cache endpoints. Jetpacked resolves those placeholders during deployment, so you do not have to hardcode localhost, generated passwords, or service hostnames.
Yes. Every project gets a Jetpacked subdomain first, and you can connect your own domain on plans that include custom domains (Starter, Pro, Power). Custom domains include automatic HTTPS.
Not yet, but it is on the roadmap. Jetpacked is built with this in mind, but it needs more work before we can ship it to customers in a way that feels simple and reliable.
Free can sleep after inactivity to save shared server resources. When someone visits the app again, Jetpacked wakes the container and shows a short starting screen while it boots. Starter, Pro, Power stay always-on.
Workers are background processes that run alongside your app: queue consumers, cron jobs, or any long-running task that is not part of the web server process. Workers are included on plans that enable them (Starter, Pro, Power).
Any site built with a static site generator (Astro, VitePress, Hugo, etc.) or a pure SPA with no server runtime. Static apps are always free, hosted via CDN, and not counted against your dynamic project limit.
Yes. When Jetpacked detects multiple deployable projects inside a single repository, it shows you a picker so you can select which one to deploy. Once you pick, that choice is saved. Future deploys and auto-deploys go straight to the right subdirectory without asking again.
Dynamic apps get a persistent storage volume mounted at /data. Anything your app writes there survives restarts and redeploys: uploaded files, generated assets, local caches, or any other data your app produces at runtime. Storage is not lost when a new version of your app is deployed.
Storage limits depend on your plan. Current app storage ranges from 1 GB to 50 GB. You can see your current limit in your project settings.
Yes. Jetpacked runs nightly backups at 02:00 UTC for all projects. Each backup captures your persistent storage volume and your database in a single encrypted snapshot. Backups are encrypted with AES-256-GCM before leaving your server and stored securely in object storage. You can download them from the Backups tab on your project. Automated restore is on the roadmap.
Backup and log retention are plan-based (7 days). You can see your current retention window in your account and project settings.
Yes. Every backup is encrypted with AES-256-GCM using a server-side master key before it is stored. The encrypted data is what gets written to object storage. Jetpacked never stores unencrypted backups at rest.
Jetpacked's deployment engine handles repository analysis with predefined rules for frameworks, runtimes, dependencies, services, and deployment patterns. AI is only used for narrow recovery tasks, such as suggesting a missing start command, runtime version, or deployment failure explanation. It receives structured metadata or redacted logs, not your source code or stored secrets. Stored environment variables, generated credentials, tokens, and private configuration are not sent to AI providers.
Environment variables and generated service credentials are stored encrypted. Known secrets are also redacted from deployment diagnostics before AI-assisted failure analysis runs.
Connect GitHub, choose your app, and let Jetpacked prepare the pieces around it.
Launch with Jetpacked