Missing documentation: how to interface with an existing coopcloud deployment #276

New Issue

rscmbbng · 2025-05-12T08:59:00Z

rscmbbng commented

2025-05-12 08:59:00 +00:00

Hello!

I've finally taken some time to study abra/coopcloud in more detail and I'm missing a substantial gap in the docs: namely how to use the tooling to query an existing deployment?

Specifically, I'm trying to onboard myself to lumbung.space maintenance. I have ssh access and added the machine to abra server list, but I can not figure out how to use abra to query which recipes/apps are running on that server. Should I be able to do so? I think so, and the commands seem to suggest it (abra app list -s lumbung.space) but the docs offer no guidance :)

Perhaps I am misunderstanding the purpose of abra, but I'm looking to do the following:

connect to an existing server
learn which apps are running on that server
query the specific apps to learn things like what version it is on and how that compares to the recipe book

Any pointers are helpful and in return I can make a PR on the docs to clarify this usecase!

Hello! I've finally taken some time to study abra/coopcloud in more detail and I'm missing a substantial gap in the docs: namely how to use the tooling to query an existing deployment? Specifically, I'm trying to onboard myself to lumbung.space maintenance. I have ssh access and added the machine to `abra server list`, but I can not figure out how to use abra to query which recipes/apps are running on that server. Should I be able to do so? I think so, and the commands seem to suggest it (`abra app list -s lumbung.space`) but the docs offer no guidance :) Perhaps I am misunderstanding the purpose of abra, but I'm looking to do the following: * connect to an existing server * learn which apps are running on that server * query the specific apps to learn things like what version it is on and how that compares to the recipe book Any pointers are helpful and in return I can make a PR on the docs to clarify this usecase!

decentral1se commented

2025-05-13 00:01:51 +00:00

Heyyyy @rscmbbng, that's all great to hear. Flying by but here's some more breadcrumbs...

abra is just a convenience wrapper for doing all sort of maintenance things. To connect to your server, you'd use plain 'ol ssh. If you wanna drop into a container of one of the apps tho, you could e.g. abra app run <domain> bash (which is more convenience than all the ssh / docker stuff you'd have to run otherwise).

I'm not sure if you've gotten the onboarding from the Autonomicz or whoever is taking care of stuff these days but you'll need to get a copy of all the app .env configs for lumbung.space to get started. When you abra app new foo, it creates ~/.abra/servers/<server>/foo.env. That file contains config and let's abra understand which apps are deployed.

This is a bit tricky to explain as it's quite an involved setup... somewhat documented on https://docs.coopcloud.tech/operators/handbook/#sharing-abra but i hope you have someone you can ask about this 🙃

You can abra app ls -s lumbung.space to get the list of apps on the server (local read) and pass -S to query the live deployment for version information. abra app ps foo.lumbung.space will give you more specific live deployment info for a specific app.

abra app ls ... should show you available updates. You can also abra recipe versions <recipe> | less to see available versions.

Any and all docs patches are welcome!

Heyyyy @rscmbbng, that's all great to hear. Flying by but here's some more breadcrumbs... `abra` is just a convenience wrapper for doing all sort of maintenance things. To connect to your server, you'd use plain 'ol `ssh`. If you wanna drop into a container of one of the apps tho, you could e.g. `abra app run <domain> bash` (which is more convenience than all the `ssh` / `docker` stuff you'd have to run otherwise). I'm not sure if you've gotten the onboarding from the Autonomicz or whoever is taking care of stuff these days but you'll need to get a copy of all the app `.env` configs for lumbung.space to get started. When you `abra app new foo`, it creates `~/.abra/servers/<server>/foo.env`. That file contains config and let's `abra` understand which apps are deployed. This is a bit tricky to explain as it's quite an involved setup... somewhat documented on https://docs.coopcloud.tech/operators/handbook/#sharing-abra but i hope you have someone you can ask about this 🙃 You can `abra app ls -s lumbung.space` to get the list of apps on the server (local read) and pass `-S` to query the live deployment for version information. `abra app ps foo.lumbung.space` will give you more specific live deployment info for a specific app. `abra app ls ...` should show you available updates. You can also `abra recipe versions <recipe> | less` to see available versions. Any and all docs patches are welcome!

rscmbbng commented

2025-05-13 08:20:31 +00:00

I'm not sure if you've gotten the onboarding from the Autonomicz or whoever is taking care of stuff these days but you'll need to get a copy of all the app .env configs for lumbung.space to get started. When you abra app new foo, it creates ~/.abra/servers/<server>/foo.env. That file contains config and let's abra understand which apps are deployed

Aha so this where I misunderstood the process. The info about apps is not on the server but in someone's abra config!

> I'm not sure if you've gotten the onboarding from the Autonomicz or whoever is taking care of stuff these days but you'll need to get a copy of all the app `.env` configs for lumbung.space to get started. When you abra app new foo, it creates `~/.abra/servers/<server>/foo.env`. That file contains config and let's abra understand which apps are deployed Aha so this where I misunderstood the process. The info about apps is not on the server but in someone's abra config!

🚀 1

decentral1se commented

2025-05-13 21:52:06 +00:00

It's kind of a mix of both tbh, because the .env values are injected into the containers runtime and some other stuff is attached onto the image via labels and such. Then abra tries to make it clear what is local / remote. But yeh, getting a copy of the shared .env files of lumbung.space is the first step.

It's kind of a mix of both tbh, because the `.env` values are injected into the containers runtime and some other stuff is attached onto the image via labels and such. Then `abra` tries to make it clear what is local / remote. But yeh, getting a copy of the shared `.env` files of `lumbung.space` is the first step.

Sign in to join this conversation.

2 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: toolshed/docs.coopcloud.tech#276