NewSchokr 13 is here. A whole new UI, seven locations, snapshots and more. Read more →

How to update your app without losing data

Ship a new version of your app on Schokr safely: back up, replace code files in the file manager, keep your data and .env, then restart.

Updated · 2 min read

To update an app on Schokr, take a snapshot or backup, upload the changed code files with the file manager, keep your .env and data files in place, and restart the server. Dependencies reinstall on start if your dependency file changed.

Before you update

  1. Take a snapshot or backup. If the new version breaks, you can roll back in minutes. Each server has 3 snapshot slots on the free package.
  2. Know which files are data. These must not be overwritten:
    • .env and other config with secrets
    • SQLite databases (.db, plus -wal and -shm files)
    • Upload folders and log files

Keeping data in a dedicated folder, such as data/, makes updates much safer.

Update steps

  1. Build locally if your app needs a build step (Next.js, Vite, TypeScript).
  2. Stop the server, or be ready to restart it right after uploading.
  3. Upload the changed files with the file manager. For many files, zip them locally (without node_modules, venvs, .env or data) and extract the archive on the server, overwriting the old code.
  4. If you renamed or removed files, delete the old copies so stale code does not get loaded.
  5. If package.json or requirements.txt changed, upload the lock file too, so the install on startup matches.
  6. Start the server and watch the console for errors.
  7. Test the main pages or commands.

Rolling back

If the new version fails and you cannot fix it quickly, restore the snapshot or backup you took. Restoring replaces the server's files with that saved state, so any data written since then is lost. That is another reason to keep data separate and back it up on its own.

Database migrations

If the new version changes your database schema:

  • Run migrations at startup, before the server begins serving. For example Django's python manage.py migrate --noinput, Prisma's npx prisma migrate deploy, or Alembic's alembic upgrade head.
  • Make migrations backwards compatible where you can, so rolling back the code does not break on the new schema.

Reducing downtime

A restart usually takes a few seconds. To keep that short:

  • Build locally rather than on startup.
  • Avoid reinstalling dependencies when they have not changed.
  • Make your app start quickly and do slow warm-up work after it begins listening.

Keep versions straight

Use Git on your own machine, tag each release, and note which version is deployed. When something breaks, you can compare exactly what changed. A /version endpoint or a startup log line with your version number helps:

console.log('Starting my-app', require('./package.json').version)