Skip to content

Container aliasing#1777

Open
ErnestoMuniz wants to merge 5 commits intohenrygd:mainfrom
ErnestoMuniz:container-alias
Open

Container aliasing#1777
ErnestoMuniz wants to merge 5 commits intohenrygd:mainfrom
ErnestoMuniz:container-alias

Conversation

@ErnestoMuniz
Copy link
Copy Markdown

@ErnestoMuniz ErnestoMuniz commented Feb 27, 2026

📃 Description

This pull request introduces container aliasing with support for both manual and automatic alias management.

closes #1385

🪵 Changelog

➕ Added

  • Show container alias as first option and fallback to container name, both in the all containers table and in the charts.
  • Manual alias editing in the "all containers" table.
  • Auto container aliasing option in the system editing dialog.
  • You can still see the original container name if you hover over the alias in the all container table.

📷 Screenshots

image image image

Copy link
Copy Markdown
Owner

@henrygd henrygd left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you, I appreciate your work on this.

However, I'm not sure that sending across all labels and controlling an alias in the UI is the best way to solve this problem.

It adds a potentially huge amount of extra data to transfer and store (containers can have thousands of labels), and the UI option may confuse people who aren't already familiar with this issue.

I'm a bit swamped at the moment, but I'll spin this up when I have time and spend a bit more time thinking about the best way to handle this.

@svenvg93
Copy link
Copy Markdown
Collaborator

svenvg93 commented Mar 9, 2026

Just my two cents: wouldn’t it be easier to read a label like beszel.name=<container_id>? If that label is set on the container, it could be used as the container name.

@henrygd
Copy link
Copy Markdown
Owner

henrygd commented Mar 9, 2026

We were talking about adding a CONTAINER_LABEL env var in #1385 which would work similarly but can be set to use existing labels like coolify.serviceName. So you wouldn't need to define a custom label for every container.

But the problem is that multiple containers could have the same value for a label, and the charts don't handle this properly because we rely on the container name being unique to link different records together.

We would probably need to store the container ID and link them with that. But that's not ideal because 1) it adds more data and 2) more importantly, IDs change when containers are recreated, which would break the continuity in the charts. So I'm not sure what the best solution is.

Maybe we could just do something in the UI where we detect if that system has a container starting with coolify and, if so, trim off the UUID suffix of all containers for that system wherever we display the container names (chart tooltip, All Containers table).

@svenvg93
Copy link
Copy Markdown
Collaborator

Maybe we could just do something in the UI where we detect if that system has a container starting with coolify and, if so, trim off the UUID suffix of all containers for that system wherever we display the container names (chart tooltip, All Containers table).

This would only work for Coolify. There are other platforms that could benefit from a similar solution, but that would require adding specific support for each of them.

That’s why I suggested using a custom label instead. It allows users to decide whether they want to use it or not and covers more use cases in my opinion. The agent could simply replace the current name value with the one defined in the label.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[Feature]: Container identifier alternatives

3 participants