Support workerpool cert replacement without recreation
Currently, workerpool reset operation regenerates the pool token, which is useful for recovery if the token is leaked. However, the documentation also suggests using this operation if the certificate is leaked — but in practice, the certificate (and its private key) is not regenerated during reset.
If the private key used to sign the workerpool certificate is compromised, the only current way to replace it is by recreating the entire workerpool. This is problematic when the workerpool is in use, as it’s attached to multiple stacks that cannot easily be reconfigured in a programmatic way.
Attempting to replace the certificate (CSR and private key) via Terraform currently results in an error, as certificate changes require workerpool recreation. This makes it impossible to recover from a leaked certificate without disrupting stacks.
Proposed improvements:
Support in-place certificate rotation (provide new CSR) without recreating the workerpool.
Allow combining token reset and certificate rotation in a single operation.
Make both actions available via Terraform as well as the UI.
This —as the current reset operation— still implies that workers will need to be recreated to fetch the new certificate and credentials, which is expected and desirable.
Benefits:
Enables secure recovery from leaked or compromised workerpool certificates without service disruption.
Aligns actual behaviour with documentation suggestions.
Improves Terraform parity with UI functionality.
Log in to comment and vote
Comments1
Jonah Kowall
Jul 30
Thanks for the careful writeup, and apologies for the confusion here. Good news: in-place certificate rotation is supported, and the docs are what let you down.
The
workerPoolResetoperation accepts a new certificate signing request and rotates the certificate and the token together in a single operation, no pool recreation and no stack reconfiguration. In Terraform, changingcsronspacelift_worker_poolperforms that rotation in place. That behavior landed in provider v1.22.0 (2025-05-07). If you were pinned below that version you'd have seen exactly what you describe, becausecsrpreviously forced replacement. Upgrading should resolve it. Your workers will still need to be recycled to pick up the new credentials, which as you noted is expected.You were right that our documentation is wrong. It recommends Reset for a compromised certificate without explaining that you can supply a new CSR as part of it. We're correcting that page, and we're tracking adding the same option to the Reset dialog in the UI for parity.
Could you confirm which provider version you were on when you hit the recreation error? That will tell us whether upgrading fully closes this for you or whether there's a second issue we should chase.