Skip to main content
The recommended way to deploy a migrated Solana squid is the zero-downtime resync procedure: deploy into a new slot, wait for it to catch up, then swap the production tag. That gives you a clean re-index with the new field selection and catches mistakes in cold blocks before traffic hits the new deployment.
The procedure below avoids the re-sync but is not recommended. It edits the status schema directly, has no rollback path beyond restoring a database backup, and assumes your codebase is version-controlled with a single processor.

​
Why you might need this

Re-syncing a Solana squid is expensive in time and Portal traffic. If your indexer has been running for months and a re-sync would take days, you may want to keep the current cold-block state and only re-deploy the processor.

​
Procedure

Assuming your squid is version-controlled and has one processor:
  1. Commit your updated squid code.
  2. Stop your Cloud squid deployment.
    1. Reset your repo to the state before the updates.
    2. Add the to field to the argument of the .setBlockRange DataSourceBuilder call (likely in ./src/main.ts). Set it to the current slot number.
    3. Update your deployment without resetting its database.
    4. Watch your squid’s logs. It should be repeatedly terminating (nothing to do) and restarting.
  3. Connect to the squid’s database and update the height field of the status schema to contain slot instead of the block height of the block mentioned there.
  4. Verify the height field updated successfully by re-reading the status schema.
  5. Reset your codebase to its updated version and redeploy your squid again.
If any of your entity columns are also named height and you write block.header.height into them, the redeployed squid will start writing slots into the same column. Either rename the entity column, or also write block.header.number and update older rows to match.