If Blnk Cloud runs Core for you (managed Core), Blnk handles the upgrade. Use this guide when you deploy and operate Core yourself.
Goal
Upgrading should not surprise your app. If a release changes how something works, follow that release’s migration guide and update your app or config so behaviour stays what you expect, or so you knowingly adopt the new behaviour.How to go from any version to any later version
- Write down your current Core version and the version you want, preferably the latest version.
- From the migration guide index, open every migration guide for a version after your current version and up to your target. Read them oldest first.
- For each guide: check if it affects you, then do the steps so your app keeps working the way you need.
- Only then deploy the new Core version.
Upgrading from
0.10.4 to 0.15.2 means reading 0.10.5, 0.11.0, 0.12.0, 0.13.2, 0.14.0, 0.15.0, then 0.15.1 before you deploy.Migration guide index
Use this table to see which guides apply to your upgrade. Open every guide for a version newer than your current Core and not newer than your target.
When new migration guides ship, they appear here and in the sidebar. The upgrade process stays the same.
For features and fixes that are not breaking changes, see the Blnk Core changelog.
Production upgrade checklist
1
Note what you run today
Record your current Core version, Typesense version if you use search, SDK versions, and the flows you care about (bulk transfers, inflight commit or void, API keys, hooks, metadata, search, custom lock settings).
2
List the guides you must read
From the migration guide index, take every version newer than your current Core and not newer than your target. Open those guides oldest first.Example: on
0.12.1 going to 0.15.2, read 0.13.2, then 0.14.0, then 0.15.0, then 0.15.1. Skip guides at or below your current version.3
Update your app where needed
Follow each guide. If a guide shows how to keep old behaviour, use that unless you mean to switch. Prefer setting the behaviour you want in requests or config instead of relying on a changed default.
4
Try the upgrade on staging first
Use a copy of production data if you can. Run the upgrade, then exercise your critical flows and check that responses and webhooks still match what you expect.
5
Back up before production
Back up Postgres before you upgrade production. If you rely on work still in the queue, note Redis and queue state as well.See Backup to disk and Backup to S3.
6
Deploy
Use the same approach as Deploy: move server and worker to the same new version, let startup run database migrations, and keep shared Postgres and Redis config aligned.
7
Check after deploy
Confirm the service is healthy, post a few test ledger transactions, confirm queued work is processing, and confirm auth still works. Finish any post-upgrade steps from the guides you followed (for example new API keys after 0.12.0, or stuck lock cleanup after 0.15.1).