Hey folks, Marcin here, person originally responsible for this design. In retrospect, it’s not great. It also underlies a lot of the system, think an original sin sort of decision. The effect is amplified by the fact that these slug IDs also double as unique identifiers of spacelift_stack Terraform resources and lots of folks still use very old versions of our provider.
While it would be possible to run a multi-month massive migration to this effect, it’s also unlikely to be worth the inconvenience caused. Selfishly, we also need to pick our battles. I think we have bigger fish to fry and while it’s not the pinnacle of software design as you correctly pointed out and I’m happy to take the blame, it’s also not a major problem in practice.
Stack IDs should be a unique ID, not the name of the stack
Right now during stack creation the ID generated for it (stack slug) is the name of the stack.
When the stack is renamed, the ID is not changed and can cause confusing situations when for example using the CLI.
Ideally, the stack ID is a unique ID and unrelated to the stack name.
Natalia Gazda
Team•
Oct 30, 2024
@Joost Polley thanks for the request! We evaluated it, and we understand the point and thinks there is sense in doing that, however it would not be a top priority for us now. Switching to autogenerated IDs would require ongoing support for two types of IDs, making it a longer-term project. I’ll leave it in “Gathering Votes” and we’ll revisit it next year.
Rose Newt
•
Nov 25, 2024
I wish to second this. Provisioning spacelift via TF provider and providing the ID’s would make provisioning and management so much easier. Currently we have automation asking the users for a space name they want, but when the automation creates it, its ID is autogenerated. This makes later automation to remove or archive the spaces difficult, as we dont want to then store that ID elsewhere so that users can request it removed when required.
Rose Beaver
•
Jan 21
I have struggled with slugs a few times. First they need to be account-unique, not space-unique, second they cannot be changed easily and finally they are used in GHA naming…
In a way, the AWS-style IDs really work well in this regards: stack-<UNIQUE_ID>, although, not perfectly human-readable.
Blue Brownie
•
Jan 23
Anything that is tied to a space at creation time should only be required to have space specific uniqueness.
Space structure: root / \ A B
Anything tied to space A should not conflict with space B and vice versa. This should apply for child spaces under A/B as well.
Natalia Gazda
Team•
Jul 16, 2025
Hey @Dom Colangelo, thanks for submitting that!
I totally understand the issue, and I agree that our name < - > slug connection is not ideal, and may cause some hiccup, but unfortunately that’s not something we would have the bandwidth to change any soon. It would be a quite significant amount of work, for not such a huge gain. I’ll leave it in gathering votes for now thoug to see wetaher it gets traction from other customers as well.
Log in to comment and vote
Comments7
Black Breeze
Jan 28
Hey folks, Marcin here, person originally responsible for this design. In retrospect, it’s not great. It also underlies a lot of the system, think an original sin sort of decision. The effect is amplified by the fact that these slug IDs also double as unique identifiers of
spacelift_stackTerraform resources and lots of folks still use very old versions of our provider.While it would be possible to run a multi-month massive migration to this effect, it’s also unlikely to be worth the inconvenience caused. Selfishly, we also need to pick our battles. I think we have bigger fish to fry and while it’s not the pinnacle of software design as you correctly pointed out and I’m happy to take the blame, it’s also not a major problem in practice.
Blue Puzzle
Jan 28
•Merged request
•5 votes
Stack IDs should be a unique ID, not the name of the stack
Right now during stack creation the ID generated for it (stack slug) is the name of the stack.
When the stack is renamed, the ID is not changed and can cause confusing situations when for example using the CLI.
Ideally, the stack ID is a unique ID and unrelated to the stack name.
Natalia Gazda
Oct 30, 2024
@Joost Polley thanks for the request! We evaluated it, and we understand the point and thinks there is sense in doing that, however it would not be a top priority for us now. Switching to autogenerated IDs would require ongoing support for two types of IDs, making it a longer-term project. I’ll leave it in “Gathering Votes” and we’ll revisit it next year.
Rose Newt
Nov 25, 2024
I wish to second this. Provisioning spacelift via TF provider and providing the ID’s would make provisioning and management so much easier. Currently we have automation asking the users for a space name they want, but when the automation creates it, its ID is autogenerated. This makes later automation to remove or archive the spaces difficult, as we dont want to then store that ID elsewhere so that users can request it removed when required.
Rose Beaver
Jan 21
I have struggled with slugs a few times. First they need to be account-unique, not space-unique, second they cannot be changed easily and finally they are used in GHA naming…
In a way, the AWS-style IDs really work well in this regards: stack-<UNIQUE_ID>, although, not perfectly human-readable.
Blue Brownie
Jan 23
Anything that is tied to a space at creation time should only be required to have space specific uniqueness.
Space structure:
root
/ \
A B
Anything tied to space A should not conflict with space B and vice versa. This should apply for child spaces under A/B as well.
Natalia Gazda
Jul 16, 2025
Hey @Dom Colangelo, thanks for submitting that!
I totally understand the issue, and I agree that our name < - > slug connection is not ideal, and may cause some hiccup, but unfortunately that’s not something we would have the bandwidth to change any soon. It would be a quite significant amount of work, for not such a huge gain. I’ll leave it in gathering votes for now thoug to see wetaher it gets traction from other customers as well.
Hope you understand!