jetpacked.ai

Three things that used to trip up a lot of apps on Jetpacked are now solved at the platform level. No configuration required, no extra services to set up. They are just there.

Persistent Storage

One of the most common problems people run into when deploying apps is that files disappear.

You build a feature that lets users upload a photo. It works. You push a bug fix. The photos are gone. This is not a bug in your app — it is how most hosting platforms work. Every deployment starts from a clean slate. Anything your app wrote to disk between deploys gets wiped.

Until now, the only way around this was to upload files to an external storage service like S3. That works, but it adds complexity: a new service to set up, credentials to manage, a different API to learn.

Starting today, every dynamic app on Jetpacked gets a persistent storage volume mounted at /data.

Anything your app writes to /data survives across deployments and restarts. It is real persistent disk, not a temporary cache. If you push ten deploys in a row, the files are still there.

What this is great for

SQLite databases. A lot of AI-built apps use SQLite because it is simple and requires no separate database server. The catch is that SQLite lives on the filesystem. With persistent storage you can put your database at /data/db.sqlite and it will never disappear.

Uploaded files. Profile photos, documents, generated PDFs. Write them to /data/uploads/ and they stay put.

App-generated data. Caches, logs, any state your app builds up over time. If it lives in /data, it persists.

How to use it

Point your app at /data as the base directory for anything you want to keep. That is the entire setup. There is nothing to enable, no environment variable to set, no storage bucket to create.

# A SQLite database that survives every deploy
DATABASE_URL=file:/data/db.sqlite

# Uploaded files that stick around
UPLOAD_DIR=/data/uploads

Your plan includes a storage allocation that you can see in the project settings. The settings page shows you how much you are using and how much you have left.

Nightly Backups

Persistent storage is only useful if you can recover it when something goes wrong. A bad deploy, an accidental rm, a corrupted SQLite file. It happens. So alongside persistent storage, we are shipping automatic nightly backups.

Every night at 02:00 UTC, Jetpacked backs up two things for each of your dynamic apps: the contents of your /data volume and, if your app uses a Postgres database, a full database dump.

Encryption

Every backup is encrypted before it leaves your server. We use AES-256-GCM, the same standard used by banks and governments. The encrypted backup is what gets stored. Even in the unlikely event that someone gained access to the backup storage, they would not be able to read your data without the key.

You never have to configure any of this. The encryption happens automatically, on every backup, every night.

Downloading a backup

Backups are available in the project settings under the Backups tab. Each entry shows the date and total size, with download buttons for the app data archive and the database dump. When you click download, the file is decrypted on our servers and delivered to your browser as a clean, ready-to-use file — a .tar.gz for your app data and a Postgres dump file for the database.

Restore

One-click restore is on the roadmap. For now you can download the files and restore them manually — the database dump is a standard pg_restore-compatible format and the app data archive is a plain tarball. We know that is not ideal and we are working on making the recovery experience as simple as the backup experience.

Ephemeral Builds

The second update is about what happens when you push code and Jetpacked starts building your app.

Before this change, builds ran directly on your deploy server — the same machine that was already running your app in production. That worked, but it was not ideal. Build tools, temporary files, and npm caches were all piling up on the same machine your app lived on.

Now every build gets its own dedicated machine that exists only for the duration of that build.

How it works

When you push to GitHub, Jetpacked spins up a fresh build machine. Your repository is cloned to it using a temporary token that expires the moment the build is done. The machine compiles your app, produces a Docker image, and pushes it to a private registry. Then the machine is destroyed.

Your production server never touches your source code. It only pulls the final Docker image.

The machine

Each build machine is gets 2 dedicated CPU cores and 4 GB of RAM. This is a meaningful step up from the shared CPU machines that free-tier builds used to run on. Builds that used to take several minutes are significantly faster.

The machine is ephemeral by design. It boots cold, does exactly one job, and is gone. There is no state that accumulates, no leftover files from previous builds, no way for one project's build to affect another. Each build starts completely clean.

Security

Your code never touches a long-lived machine. The GitHub token used to clone your repository is a short-lived installation token scoped only to that repository. It is generated right before the clone and is not stored anywhere after the build completes. By the time the build machine is destroyed, there is nothing left: no source code, no secrets, no credentials.

The Docker image that gets produced is pushed to a private registry that only your deploy servers can access. Your source code is never in the final image unless you explicitly copy it in.

All three of these changes are live now for all accounts. Persistent storage is automatically available to every dynamic project — existing projects already have the volume mounted on their next deployment. Backups start running tonight and will appear in your project settings tomorrow morning. Ephemeral builds are the default for all new and existing deploys going forward.

If you run into anything unexpected, reach out.

Persistent Storage, Encrypted Backups, and Ephemeral Builds Are Now Live