At present, Portainer is built on the one server multiple agents model where you have one environment that is your “management” interface and runs Portainer Server, and the others use the Agent to interface with the Server. You can only log into the environment running the Portainer Server container, not the Agents. We don’t currently support multi-tenancy of the Portainer Server.
In production setups we generally recommend a separate environment purely for management, where workloads don’t run, that you run the Portainer Server on, and all workload environments use Agents. This way if one of your workload environments goes down, you can still manage the others in the meantime.
The reason this happens is because when a stack is created with compose via the CLI, there is no back reference to the compose file that created the resulting stack. As such, Portainer has no way of knowing how the stack was created and for safety we flag these as limited stacks. If the stack is deployed through Portainer, we save the compose file and reference it in our database to that stack.
The directory names within the Portainer data volume are given numerical identifiers because stack names can change, and because we let you manage multiple environments from one Portainer instance we also need to allow for the same stack name to exist on more than one environment. The directories weren’t initially intended for direct access outside of Portainer.