feat: abra app clone <srcdomain> --domain <newtargetdomain> #730

New Issue

notplants · 2025-11-15T21:03:37Z

notplants commented

2025-11-15 21:03:37 +00:00

Possible proposal for a new abra command that creates a new app with the same config (other than domain) and optionally same secrets as the source of the clone. I imagine this clone command not necessarily trying to copy all the data over like move (although that could also be an optional argument).

abra app clone <srcdomain> --domain <newtargetdomain> [options]

Optional Arguments

--server <targetserver>
Clone the app onto a different server.
Default: same server as the source app.

--keep-secrets ALL
Reinsert duplicates of all existing secrets from the original app.

--keep-secrets <secret1,secret2,...>
Provide a comma-separated list of secrets to keep.
Secrets not listed will be newly regenerated during cloning.

I found myself wanting such an abra command. If there was interest in adding such a command, I could also imagine working on it as a way to get to know abra better. I imagine it would be somewhat similar to the recently added move command.

Possible proposal for a new abra command that creates a new app with the same config (other than domain) and optionally same secrets as the source of the clone. I imagine this clone command not necessarily trying to copy all the data over like move (although that could also be an optional argument). __________________ `abra app clone <srcdomain> --domain <newtargetdomain> [options]` Optional Arguments --server <targetserver> Clone the app onto a different server. Default: same server as the source app. --keep-secrets ALL Reinsert duplicates of all existing secrets from the original app. --keep-secrets <secret1,secret2,...> Provide a comma-separated list of secrets to keep. Secrets not listed will be newly regenerated during cloning. __________________ I found myself wanting such an abra command. If there was interest in adding such a command, I could also imagine working on it as a way to get to know abra better. I imagine it would be somewhat similar to the recently added `move` command.

notplants changed title from ~~`abra app clone <appname> --domain <newdomain>`~~ to `abra app clone <olddomain> --domain <newdomain>`

2025-11-15 21:04:20 +00:00

notplants changed title from ~~`abra app clone <olddomain> --domain <newdomain>`~~ to `abra app clone <srcdomain> --domain <newdomain>`

2025-11-15 21:04:30 +00:00

notplants changed title from ~~`abra app clone <srcdomain> --domain <newdomain>`~~ to feat: `abra app clone <srcdomain> --domain <newdomain>`

2025-11-15 21:05:26 +00:00

notplants changed title from ~~feat: `abra app clone <srcdomain> --domain <newdomain>`~~ to feat: `abra app clone <srcdomain> --domain <newtargetdomain>`

2025-11-15 21:08:17 +00:00

notplants commented

2025-11-16 15:04:53 +00:00

Also sharing a specific usecase here where I wanted this command:

while working on https://docs.coop , it seems like probably we will have multiple docs instances that all share one separate keycloak instance.

I could make a mini bash script to make a new "cloned" instance with the same configs other than domain, but I wondered if this type of small automation was general enough to be in abra itself

Also sharing a specific usecase here where I wanted this command: while working on https://docs.coop , it seems like probably we will have multiple docs instances that all share one separate keycloak instance. I could make a mini bash script to make a new "cloned" instance with the same configs other than domain, but I wondered if this type of small automation was general enough to be in abra itself

decentral1se commented

2025-11-18 22:09:46 +00:00

@notplants I think I may not be getting this one fully, apologies in advance.

There seems to be some overlap with move in this proposal. If it does indeed move the data then i think it's doing nearly exactly the same thing exact the "new server" is the same as the "old server"?

I am not sure why you'd want to clone the secrets, wouldn't that mean you'd have to regenerate them as you'd have 2 apps with the same secrets? Do you mean, you want to generate new secrets for the cloned app?

Any further info / "explain it like im 5" is much appreciated 🙏

@notplants I think I may not be getting this one fully, apologies in advance. There seems to be some overlap with `move` in this proposal. If it does indeed move the data then i think it's doing nearly exactly the same thing exact the "new server" is the same as the "old server"? I am not sure why you'd want to clone the secrets, wouldn't that mean you'd have to regenerate them as you'd have 2 apps with the same secrets? Do you mean, you want to generate new secrets for the cloned app? Any further info / "explain it like im 5" is much appreciated 🙏

decentral1se added the

enhancement

label 2025-11-18 22:10:10 +00:00

notplants commented

2025-11-19 16:34:41 +00:00

@decentral1se I'm not totally sure if I'm not being clear, or also possibly its just not a very common thing to want to do other than the specific deployment I'm talking to. will try to explain the docs.coop case more:

so in this particular autonomic deployment, each of the lasuite-docs instances will share the same keycloak and email provider, even though they are separate apps of lasuite-docs (e.g. three lasuite-docs instances: org1.docs.coop, org2.docs.coop, somethingelse.net).

so each of these apps will have the same configuration other than domain, and they will each share the same secrets relating to communication with the e-mail provider.

so when a new client wants docs instance, I want to simply run one command that creates a new app and deployment for them that is ready to go (e.g. org3.docs.coop). this new app and deployment could be on the same server, or on a different server -- the key thing is just that its exactly the same as the previous deployment, except with a new domain. in this case, we don't actually need it to copy data over (it should be a fresh slate of data, like a new app).

like I said before, I could also make a pretty simple bash script that does this... something like:

'abra new --domain org3.docs.coop'
use templating to modify the .env for this new app appropriately based on my own custom default .env
abra app secret insert email_pass (with the correct e-mail password)
abra app deploy

Unlike move, this set of command should not remove the previous app or deployment.

Something like this clone command could also potentially be used for the purpose of testing, if you want to clone an app to a testing environment, and make changes and see what happens -- although side rabbit hole: with the case of copying data AND changing the domain, many apps probably would additionally require an app-specific change_url hook (like yunohost has) which makes any necessary data changes based on the new url, in addition to config changes.

Or in the most minimal metaphor explanation, like unix commands, this would be "cp" instead of "mv" but also calling "change_url" after "cp".

Let me know if that clarifies, or also if it clarifies and its just something that doesn't come up often :)

@decentral1se I'm not totally sure if I'm not being clear, or also possibly its just not a very common thing to want to do other than the specific deployment I'm talking to. will try to explain the docs.coop case more: so in this particular autonomic deployment, each of the lasuite-docs instances will share the same keycloak and email provider, even though they are separate apps of lasuite-docs (e.g. three lasuite-docs instances: org1.docs.coop, org2.docs.coop, somethingelse.net). so each of these apps will have the same configuration other than domain, and they will each share the same secrets relating to communication with the e-mail provider. so when a new client wants docs instance, I want to simply run one command that creates a new app and deployment for them that is ready to go (e.g. org3.docs.coop). this new app and deployment could be on the same server, or on a different server -- the key thing is just that its exactly the same as the previous deployment, except with a new domain. in this case, we don't actually need it to copy data over (it should be a fresh slate of data, like a new app). like I said before, I could also make a pretty simple bash script that does this... something like: - 'abra new --domain org3.docs.coop' - use templating to modify the .env for this new app appropriately based on my own custom default .env - `abra app secret insert email_pass` (with the correct e-mail password) - abra app deploy Unlike `move`, this set of command should not remove the previous app or deployment. Something like this clone command could also potentially be used for the purpose of testing, if you want to clone an app to a testing environment, and make changes and see what happens -- although side rabbit hole: with the case of copying data AND changing the domain, many apps probably would additionally require an app-specific `change_url` hook (like yunohost has) which makes any necessary data changes based on the new url, in addition to config changes. Or in the most minimal metaphor explanation, like unix commands, this would be "cp" instead of "mv" but also calling "change_url" after "cp". Let me know if that clarifies, or also if it clarifies and its just something that doesn't come up often :)

👍 1

Sign in to join this conversation.

2 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: toolshed/abra#730

feat: abra app clone <srcdomain> --domain <newtargetdomain> #730

feat: `abra app clone <srcdomain> --domain <newtargetdomain>` #730