default config, lifecycle scripts) #380

New issue

Closed

opened 2026-03-15 14:09:14 +03:00 by kerem · 4 comments

kerem commented

2026-03-15 14:09:14 +03:00

Owner

Originally created by @leoberry on GitHub (Dec 10, 2025).
Original GitHub issue: https://github.com/axllent/mailpit/issues/593

Hello,

I've been using Mailpit in a production environment and I really appreciate the project. Thanks for your work!

To facilitate deployment and maintenance on Debian/Ubuntu servers, I have developed a robust packaging setup that adheres to standard Debian practices. I believe this could be a great addition to the official releases.

Currently, I have implemented:

A Production-ready Systemd Unit: Includes auto-restart policies, security hardening (capabilities, NoNewPrivileges), and standard paths.
Standard Configuration: Support for an /etc/default/mailpit file. This allows admins to define environment variables (like MP_SMTP_BIND_ADDR) or pass extra flags (via a custom MAILPIT_ARGS) without modifying the unit file itself, preserving changes across updates.
Lifecycle Scripts (postinst / prerm): Handles the creation of a dedicated system user (mailpit), permission management, and automatically enables/restarts the service upon installation or upgrade.

My Proposal: Would you be open to a PR where I integrate these configuration files into your .goreleaser.yaml (using nFPM)?

This would allow the official .deb (and potentially .rpm) releases to automatically include these improvements, making apt install mailpit fully ready-to-use out of the box.

Let me know if this sounds interesting to you!

Best regards,

Originally created by @leoberry on GitHub (Dec 10, 2025). Original GitHub issue: https://github.com/axllent/mailpit/issues/593 Hello, I've been using Mailpit in a production environment and I really appreciate the project. Thanks for your work! To facilitate deployment and maintenance on Debian/Ubuntu servers, I have developed a robust packaging setup that adheres to standard Debian practices. I believe this could be a great addition to the official releases. Currently, I have implemented: 1. A Production-ready Systemd Unit: Includes auto-restart policies, security hardening (capabilities, NoNewPrivileges), and standard paths. 2. Standard Configuration: Support for an /etc/default/mailpit file. This allows admins to define environment variables (like MP_SMTP_BIND_ADDR) or pass extra flags (via a custom MAILPIT_ARGS) without modifying the unit file itself, preserving changes across updates. 3. Lifecycle Scripts (postinst / prerm): Handles the creation of a dedicated system user (mailpit), permission management, and automatically enables/restarts the service upon installation or upgrade. My Proposal: Would you be open to a PR where I integrate these configuration files into your .goreleaser.yaml (using nFPM)? This would allow the official .deb (and potentially .rpm) releases to automatically include these improvements, making apt install mailpit fully ready-to-use out of the box. Let me know if this sounds interesting to you! Best regards,

kerem

2026-03-15 14:09:14 +03:00

closed this issue
added the
stale
label

kerem commented

2026-03-15 14:09:30 +03:00

Author

Owner

@leoberry commented on GitHub (Dec 10, 2025):

I just discovered issue #425 (which is closed). It seems my proposal addresses exactly what was discussed there.

@leoberry commented on GitHub (Dec 10, 2025): I just discovered issue #425 (which is closed). It seems my proposal addresses exactly what was discussed there.

kerem commented

2026-03-15 14:09:35 +03:00

Author

Owner

@axllent commented on GitHub (Dec 12, 2025):

Sorry about the delay getting back to you @leoberry. I must say I'm a bit confused because I do not use goreleaser to package any of Mailpit's binaries.

As you noted, I have been asked this question in the past, however I feel this should be a package maintainer's job (not mine) as they not only can provide an installer with the features you are describing (tailored to the platform's structure), but also the infrastructure to install and facilitate ongoing upgrades (ie: apt upgrade) which hosting deb files within Github Releases does not address either.

Ideally both Ubuntu and Debian would have official packages for Mailpit, but I don't know what's involved there, nor the decision process behind what apps are officially included (demand maybe, or maybe a volunteer maintainer?). Alternatively, if you're willing to maintain the Debian/Ubuntu packages (not via official channels), then you could potentially do so via Launchpad. Either way however, I do not intend to maintain this myself as there are also various RPM-based systems, nix, AppImage, snap, Alpine apks, Windows installers, Mac installers.... the list just goes on and on. Ubuntu and Debian are only one of many platforms.

@axllent commented on GitHub (Dec 12, 2025): Sorry about the delay getting back to you @leoberry. I must say I'm a bit confused because I do not use goreleaser to package any of Mailpit's binaries. As you noted, I have been asked this question in the past, however I feel this should be a package maintainer's job (not mine) as they not only can provide an installer with the features you are describing (tailored to the platform's structure), but also the infrastructure to install and facilitate ongoing upgrades (ie: `apt upgrade`) which hosting deb files within Github Releases does not address either. Ideally both Ubuntu and Debian would have official packages for Mailpit, but I don't know what's involved there, nor the decision process behind what apps are officially included (demand maybe, or maybe a volunteer maintainer?). Alternatively, if you're willing to maintain the Debian/Ubuntu packages (not via official channels), then you could potentially do so via [Launchpad](https://launchpad.net/). Either way however, I do not intend to maintain this myself as there are also various RPM-based systems, nix, AppImage, snap, Alpine apks, Windows installers, Mac installers.... the list just goes on and on. Ubuntu and Debian are only one of many platforms.

kerem commented

2026-03-15 14:09:40 +03:00

Author

Owner

@github-actions[bot] commented on GitHub (Dec 20, 2025):

This issue has been marked as stale because it has been open for 7 days with no activity.

@github-actions[bot] commented on GitHub (Dec 20, 2025): This issue has been marked as stale because it has been open for 7 days with no activity.

kerem commented

2026-03-15 14:09:45 +03:00

Author

Owner

@github-actions[bot] commented on GitHub (Dec 23, 2025):

This issue was closed because there has been no activity since being marked as stale.

@github-actions[bot] commented on GitHub (Dec 23, 2025): This issue was closed because there has been no activity since being marked as stale.