红帽（Red Hat）在开源容器管理工具Podman 4.4版本整合了Quadlet，进一步消除在Linux系统与服务管理器systemd执行容器的复杂性，让用户能够像是使用Kubernetes文件，用声明的方式定义要执行的内容。
Podman是Linux上无常驻程序的容器引擎，红帽在RHEL 8.0的时候就已经不包含Docker，不少用户转而使用Podman，而红帽提到，Podman好处之一是能够与systemd协同运行，其使用标准的fork/exec模型，因此很适应systemd系统以及服务管理器模型。
而Quadlet原本是一个自选工具，能够让用户以更好的方式，以程序管理器systemd执行Podman系统容器。之所以会有Quadlet这种工具的需求，是因为虽然容器通常在云计算环境运行，并且和Kubernetes等调度工具一起使用，主要用于开发和测试目的，因此用户能够手动管理容器。
但也有一小部分用例，需要自动容器管理，在较小的单节点上，像是嵌入式或是车用设备，缺乏系统管理员、网络连接或是边缘服务器控制，因此便可以使用systemd调度容器，虽然有很多方法可以将podman和systemd结合使用，但是通常systemd配置文件过大或是难以维护，因此在Podman集成Quadlet，便能让用户更简单地使用systemd管理Podman容器。
Podman在4.3的时候，加入了自定义健康检查操作功能，可以在容器发生问题时，自动采取诸如重新启动等措施，而systemd与Podman的结合，使这项功能有更好的发挥，能够自动更新和回退在systemd中执行的Kubernetes工作负载，用户可依赖systemd管理服务，监控工作负载的生命周期和服务状态，在故障时重新启动。
由于Podman和systemd单元文件运行良好，解决了IT管理员许多麻烦事，用户也开始向上游Podman项目提出最佳实践的请求，希望能以systemd服务形式执行Podman，因此红帽开始和systemd合作，针对最佳实践制定了模板，在Podman添加podman generate systemd指令，可以直接从正在执行的容器，创建单元文件。
之后才又进一步衍生出Quadlet项目，通过通用systemd单元文件定义动态重新生成服务，红帽解释，Quadlet对用户隐藏systemd执行容器的复杂性，即便从头开始编写单元文件也变得容易，用户可将其视为适用于systemd的Compose或Kubernetes文件。用户现在已经可以在CentOS Stream、Fedora等Linux发行版，用到已经集成Quadlet的Podman 4.4。