deploying separate applications #1576

New issue

Open

opened 2026-08-25 09:31:30 +02:00 by kiara · 0 comments

kiara commented

2026-08-25 09:31:30 +02:00

Owner

at some point we simplified out single-node deployment methods in favor of multi-node ones, figuring these would cover the same use-cases.

in practice, components to deploy this way are typically set in core/setups/hosts-common.nix, which so far simply passes thru any (selected) components of a given group - that way ensuring that an operator's LDAP would allow sharing a user set across their deployed applications. this is a framing that prioritizes needs of organizations - a use-case so far championed by @koen as well as myself.

@kerstin has noted however that admins of multiple fediverse instances might not actually think this way, instead potentially foregoing such (declarative) configuring of SSO/LDAP in favor of instances simply either public or private.
that insight may render deployment of separate applications a more legitimate user need, which could potentially work by deferring further supporting components to (potentially) shared instances at the hosting provider group.

this might then further imply that the resources/contracts currently simply provided for by hosting providers might be relevant for operators application configuration to have input on as well (which could still potentially go through a hosting provider's resource policy) - potentially related to #1279.

at some point we simplified out single-node deployment methods in favor of multi-node ones, figuring these would cover the same use-cases. in practice, components to deploy this way are typically set in `core/setups/hosts-common.nix`, which so far simply passes thru any (selected) components of a given `group` - that way ensuring that an operator's LDAP would allow sharing a user set across their deployed applications. this is a framing that prioritizes needs of organizations - a use-case so far championed by @koen as well as myself. @kerstin has noted however that admins of multiple fediverse instances might not actually think this way, instead potentially foregoing such (declarative) configuring of SSO/LDAP in favor of instances simply either public or private. that insight may render deployment of separate applications a more legitimate user need, which could potentially work by deferring further supporting components to (potentially) shared instances at the hosting provider group. this might then further imply that the resources/contracts currently simply provided for by hosting providers might be relevant for operators application configuration to have input on as well (which could still potentially go through a hosting provider's resource policy) - potentially related to #1279.

kiara added a new dependency

2026-10-01 17:27:28 +02:00

#289 key features improving user experience supported