v1.13.0: State migrations
You can now pause a Module and edit its state directly, instead of planning and applying it. Move a resource, import one, remove one, or list what's there. And with Demonolith, split a monolith into separate Modules, or move resources from one Module to another.
Full notes: 1.13.0 on GitHub.
Pause first
Editing state isn't something you want to happen by accident, so you can only do it on a paused Module. A paused Module sits still. Nothing triggers it, nothing upstream starts a run on it, and you can't apply or destroy it. Once it's paused, the state-editing options show up, and you run them one at a time.
Pausing doesn't interrupt a job that's already running, it just holds back anything new: triggers that fire while the Module is paused are queued instead of run. Resuming releases them, with the usual checks, so a queued run still waits if its dependencies or runner aren't ready.
You can cancel any step while it's running, including the write. Stopping a state edit halfway is no worse than stopping an apply halfway, and that's your call to make.
Editing one Module's state
Four of these are the state commands you already know. Each one runs a single resource at a time, so if something goes wrong you know exactly which resource it was:
- Move - rename a resource, or change where it sits in the state.
- Import - bring something that already exists under management.
- Remove - take a resource out of state without touching the real thing.
- List - see what's in the state right now.
Split and transfer
Two more work across Modules, using Demonolith:
- Split breaks a monolith into several Modules, each with its own slice of the original state.
- Transfer moves resources from one Module to another, each with its own repository, runner and backend.
Both check themselves before they commit. Snap CD plans against the state as it'll look afterwards, makes sure every Module involved comes out clean, and only then asks you to approve. You decide how many approvals it needs, per Module or across a whole Namespace. The default is one, not zero, because once a state edit is written you can't take it back.
A transfer also needs the Module on the other end to say yes. Nothing else in Snap CD touches one Module's state on behalf of another, so the receiving side has to accept it. If either side says no, the transfer ends and nothing is written.
The two Modules run on separate runners that never share a working directory. So the piece of state one hands over, and the values the other needs back, go through the Server. They're encrypted the same way state is, and thrown away once both runs are done.
Fixes
- A job could be created and then just sit there, never picked up, when SQL Server handled the messaging. The first message isn't lost anymore.
- "Kill current step" used to end the job after a timeout without actually stopping the runner. Now it stops the running command right away.
- A job could hang forever waiting for a result that had already come back a moment too early. That result no longer gets dropped.
- The API had a cancellation option that did nothing, so it's gone. The two the dashboard uses are unchanged.
Intelligent GitOps for Infrastructure as Code. Automate, orchestrate, and scale your infrastructure deployments with confidence.
© 2026 Snap CD. All rights reserved.