Scheduled deployments
For those of us who work in organizations that have strict Change Control policies, it would be nice to have a “scheduled deployment” option for Spacelift runs.
For example, if we have a proposed change to a database instance, we can prepare the Terraform PR ahead of time, approve it based on the Spacelift Plan, etc. But to actually deploy it requires hands-on-keyboard.
It would be nice if we were able to use a option to “Confirm and Deploy at SCHEDULED TIME” when finalizing our approvals in the Spacelift UI.
This is very much a Nice-To-Have feature.
Log in to comment and vote
Comments5
Natalia Gazda
Jul 19, 2025
Jade Grape
Jul 21, 2025
We’re a smaller organization, so our definition of “formal” may not line up with everyone else’s… but I’m trying to think bigger picture here.
As you guessed, the idea here is that a CAB (or equivalent) might give us a window for a change overnight or after hours. We would have the necessary IAC changes teed up - PR made, reviewed, and approved; Spacelift run Approved (but NOT Confirmed); and we’re all ready to push that button.
In Spacelift itself, we tend to be careful (and restrictive) about who is allowed to hit that Confirm button. So yes, in the situation you’re looking at, it might be a DBA or DevOps Engineer who actually has to wake up to do the work. Sometimes, of course, we would need to observe a change to ensure that it’s successful - but there are definitely times where we’re confident enough in our process that “babysitting” the run isn’t necessary.
At the moment, we generally queue up the Spacelift run the day of the maintenance - we jump through all of the approval and review hoops, check with the CAB, and have everything ready for that Confirm step. So there’s generally less than a 24 hour lead time before the change, and we typically “freeze” the Stack in preparation for that, to avoid drift from other changes. I can see a larger organization end up in a situation where they might need to resolve a conflict or drift before a scheduled deployment, though… which is definitely something to consider.
As for timing, I’d say that a deployment window (“between 2am and 4am”) would be sufficient, although given enough granularity in the configuration, someone could get sneaky and say “between 3am and 3:05am” and narrow it down fairly well, should they choose to.
Another possible option would be to allow something like “temporary delegation” of a Confirm step to another individual or group. So, for example, we might have a “Pre-Approve for Confirmation” option that would let us designate a particular change set to be applied by someone who might not normally have the permissions to deploy it. This would be more complicated on the IAM side of things, but less complicated on the scheduling.
Natalia Gazda
Aug 14, 2025
@GeoffEllingwoodBF and how about following approaches:
Option 1: Scheduled Tasks
After reviewing and approving your Terraform PR during business hours, you can create a scheduled task to apply the changes at your desired time:
yaml schedules: tasks: - command: "terraform apply -auto-approve" timestamp_unix: 1735689600 # Your scheduled deployment timeOption 2: API Automation
You could also automate this pattern using our API - when a PR is approved, automatically create a scheduled task for your next change window.
Would any of these approaches work for your use case?
Jade Grape
Aug 14, 2025
It would certainly function for our use case. I’d have to try it a bit to see how easy it is to actually do in practice, but this might be something for a FAQ somewhere (without requiring a new feature).
Natalia Gazda
Aug 20, 2025
Great, then I’ll close the ticket on our side. If there’s any help needed, feel free to reach out to our support team :)