this post was submitted on 12 May 2026
82 points (96.6% liked)

Selfhosted

59179 readers
402 users here now

A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.

Rules:

  1. Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.

  2. No spam posting.

  3. Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it's not obvious why your post topic revolves around selfhosting, please include details to make it clear.

  4. Don't duplicate the full text of your blog or github here. Just post the link for folks to click.

  5. Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).

  6. No trolling.

  7. No low-effort posts. This is subjective and will largely be determined by the community member reports.

Resources:

Any issues on the community? Report it using the report flag.

Questions? DM the mods!

founded 2 years ago
MODERATORS
ruud@lemmy.world
Loki@lemmy.world
CannaVet@lemmy.world
devve@lemmy.world
HybridSarcasm@lemmy.world
HybridSarcasm@lemmy.hybridsarcasm.xyz
82
Best way to manage all my services as containers? (lemmy.ca)
submitted 2 days ago* (last edited 2 days ago) by valar@lemmy.ca to c/selfhosted@lemmy.world
55 comments fedilink hide all child comments
 

What to people use and recommend for this? I've read a bit about portainer, but I'm still learning - and don't know what the best solutions are.

Today I have a handful of selfhosted services running on my home machine - mostly installed directly, but a couple running as docker containers. As the scale of my selfhosting has grown, I've realized that things would be a lot easier to manage if each service was run as its own container, so that installed services are isolated.

The solution I'm looking for would make it easy (possibly a web UI) for me to monitor, modify, update, and remove containerized services, including networking and storage.

Edit: Also I would only want a FOSS solution.

you are viewing a single comment's thread
view the rest of the comments
[–] jrgd@lemmy.zip 4 points 2 days ago* (last edited 2 days ago)

Starting with confirmation of what others have said, yes you can use compose tools with Podman and Podman can hook directly with Docker Compose (the tool), but it really isn't recommended. Compatibility with compose now is better than it used to be, but there are still edge cases. For a lot of projects that just pre-write a compose file that they expect to cover the general use case of their container, you're best to take the compose file and write it out to Quadlet unit(s).

Other differences not mentioned can include:

  • Podman alongside containers has optional pods, which let you wrap multiple containers together, sharing the same IP internally. Useful for having a service and their sidecar containers (e.g. Valkey, Postgres, Meilisearch, etc.) be bundled under the same IP address and simply reference each other as localhost, 127.0.0.1, or ::1. If you utilize pods for certain split-container applications, you may need to remap certain service ports as they can overlap and cause binding failures.
  • Podman has multiple networking modes. If you use Podman at the system level (rootful) like Docker expects you to, you're not really going to encounter any quirks with the default networking setup. Per-user Podman (rootless) defaults to using the Pasta backend for networking, which is still very highly performant, but is a bit clunky to configure (if ever actually necessary) and inter-pod communication can be difficult to get right. Alternatively, registering rootless pods with a bridge network makes inter-pod communication easy, but can cause problems if accurate source IPs are needed (e.g. upstream reverse proxies, accurate client IP logging, etc.).
  • Because Podman is daemonless, there is also no persistent API socket loaded by default (an intentional security choice). For both rootful and rootless containers, you can enable this manually and mount it to containers that need it. For containers that expect docker.sock explicitly for API manipulation, your mount will need to reflect the name change of the podman.socket to what the container expects.
  • Podman by default won't shorthand container pulls from docker.io by default: a sin I see constantly done in so many compose files. When pulling a container from DockerHub, you need to put the docker.io/ prefix, just as you would but the appropriate prefix with Quay, Github, Gitlab, or any other distributor.
  • Podman can optionally let you auto-update containers based on the release tag specified for the container.
  • Because of Podman's integration with SystemD, a lot of oddball integrations (external cron jobs, one-shot services, etc.) can be pulled together with extra SystemD units (services, timers, etc.).