Way to handle state in NixOps4 #169

Closed
opened 2025-02-20 12:53:16 +01:00 by kiara · 2 comments
Owner

At present, our repo has a lot of hard-coded info that in practice should not be static global state, but rather state specific to a given deployment. A current examples of this is SSH keys.

Ideally, we would instead be able to handle such state through NixOps4, so that deployments would no longer depend on our source code, but SSH keys for example could rather be generated on the fly for subsequent updates to a deployment.

At present, our repo has a lot of hard-coded info that in practice should not be static global state, but rather state specific to a given deployment. A current examples of this is SSH keys. Ideally, we would instead be able to handle such state through NixOps4, so that deployments would no longer depend on our source code, but SSH keys for example could rather be generated on the fly for subsequent updates to a deployment.
Author
Owner

estimated at ~2w

estimated at ~2w
roberth added this to the Fediversity project 2025-02-24 10:52:54 +01:00
roberth self-assigned this 2025-02-24 10:52:59 +01:00
Author
Owner

superseded by #307

superseded by #307
kiara closed this issue 2025-04-14 11:08:12 +02:00
kiara removed this from the Fediversity project 2025-06-10 18:50:26 +02:00
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Blocks
Reference
fediversity/fediversity#169
No description provided.