Templated network units, and calling templated units from statically defined units

[Clancy508]

Wasn't really sure how else to bring this up since it's a mix of some questions about Quadlet templating in general and a possible bug. I'm going to open with a bit of waffling about the use case I have in mind, skip ahead for the meat (which I hope is more broadly applicable)

I've been tinkering with templating some Quadlet network units recently out of a desire to set up a more hardened service network layout. The setup I'm working with is hosting multiple services on a single Podman host with a common reverse proxy container, and the problem I'm trying to solve is how best to connect those services to the reverse proxy in a secure but still maintainable way. I'm aware of the general recommendation to use a common reverse proxy network and then an extra network per service, but I'm not a fan of this because it allows unmediated cross connections between services - I don't want the services I'm hosting to be able to talk to each other by default.

I've thought of a few ways to achieve this sustainably but one idea I had that would seem to work with Podman's existing features, or at least could work, would be templated network files - these could be used to very easily generate a network to connect each service frontend to the reverse proxy, and each service to its support containers. The result would be the reverse proxy gets what amounts to a dedicated point-to-point link to each service, can't connect to support containers, and each service can only talk to its own support containers and the reverse proxy itself, which can choose to not expose other services on those network interfaces.

---

The issues with this approach all seem to boil down to network units not really supporting templating, and Quadlet assuming that templated units are only ever invoked either directly or by other templated units. This results in a couple of problems:

• The bug is in how network units are generated when templated with default names - if I instantiate test@1.network the default name for the result is systemd-test@-1-network which fails because Podman network names can't contain most symbols. Other templated units automatically replace the '@' with '_' and work perfectly. I suspect this is out of the originally envisioned scope of templates as there's no mention of network templating at all in the documentation so I think that it just wasn't considered as a usecase, but the thing is it almost works exactly the same as the other template units so it seems like it would be a genuinely easy fix, adding the documentation/worked examples would be harder

• Templated units can't be instantiated from static units. The documentation does state that you can only specify the template, not the specific instance, but it also only describes specifying instanced units in a container template. Static container units don't get an instance name they can pass down to instantiated volumes and such so they can't call templates directly, and calling instantiated units results in generated podman commands that have %i in them with no instance name from the systemd unit to put in there, resulting in unexpected behaviours or outright failures depending on the specifics. You can manually specify the resulting Podman label for the instance but then you don't get the automatic dependency linking and such.

I don't think my specific use case is the only situation in which you might want to instantiate multiple copies of a templated volume or network for each of a set of statically defined containers, and it seems reasonable to expect that a static container could be passed an instantiated volume or network unit and have the generator parse that and produce a working result. Ideally, this would work like a manual case of the container templates, where the generator can snatch out the instance name from the passed template and automatically generate that instance without needing to manually invoke it, the same way that a container instance would automatically create its own instance of a templated volume. From an interaction standpoint this seems pretty intuitive, it seems to align with the current templating structure pretty well, although behind the scenes the generator would have to do a bit more work since it can't rely on systemd just handling the instance name in this case. It also seems like it would cut down on a lot of boilerplate configuration, even in more conventional reverse proxy setups with one common reverse proxy network it would be very convenient to define one network template and instantiate it for each service rather than manually specifying it each time.

[mg1986jp]

You've identified a real gap — network unit templating isn't fully supported yet and the @ → _ replacement that happens for container/volume templates doesn't apply to network units. That's a legit bug worth filing.

For the naming issue specifically: network names in Podman follow DNS label rules (alphanumeric + hyphens), so the generated systemd-test@-1-network with the @ fails. The fix in the Quadlet generator would be the same @ → _ substitution already done for other unit types. If you want to push for this, file a bug referencing the code in pkg/systemd/quadlet/quadlet.go where the name sanitization happens — it handles containers and volumes but skips networks.

Workaround for the naming issue:

Set NetworkName= explicitly in your template to control the generated name:

# mynet@.network
[Network]
NetworkName=svc-%i
Subnet=10.89.%i.0/24

This avoids the broken auto-generated name. The %i expansion happens at the systemd level, so as long as your instance names are numeric or alphanumeric, the resulting Podman network name will be valid.

Workaround for static → template instantiation:

Since static units can't automatically instantiate templates, you need to be explicit. Create a small systemd drop-in or use ExecStartPre to ensure the network exists:

# myservice.container
[Container]
Image=myimage:latest
Network=svc-myservice.network

[Service]
ExecStartPre=/usr/bin/systemctl start mynet@myservice.service

[Install]
WantedBy=default.target

Or, more cleanly — define concrete network units that source from a common template via symlinks:

# Create instances as symlinks
ln -s mynet@.network mynet@proxy-svc1.network
ln -s mynet@.network mynet@proxy-svc2.network

Then reference mynet@proxy-svc1.network directly from your static container units.

For your isolation architecture: the per-service network approach is solid. An alternative that avoids the templating issues entirely: use Podman pods with --infra-container + --network flags, where each pod gets its own network and the reverse proxy pod shares networks with each service pod. But that changes the container topology pretty significantly.

The feature request for static → template instantiation in Quadlet is worth filing separately. The generator would need to parse Network=mynet@instance.network, extract the instance name, and generate the appropriate network unit — similar to how it handles volume templates from container templates.