Message Nest: one push API in front of email, DingTalk and Telegram

The copy and paste problem behind every notification script

The origin story in the README is small and honest: the author kept writing scripts that needed to send messages, kept having to integrate a different channel each time, and found it inconvenient. That produced Message Nest, a message push integration platform aimed at simplifying and customising many notification methods. The name is the point. It is a nest, a collection site where several kinds of messages gather, and the deliverable is a unified sending API. The channels listed in the README cover email, DingTalk, WeCom, Feishu, Telegram, Bark and PushMe, with the changelog adding Gotify and Ntfy in June 2026 and Aliyun SMS in December 2025. The intended user is a developer with several internal or personal projects that each need to notify someone, and who is tired of wiring each channel into each project.

One endpoint, many channels, and templates that fill in the blanks

The architecture visible in the repository is a standard Go service. The HTTP layer is Gin, with routers/ holding the routes and middleware/ holding the request pipeline, service/ holding the business logic and pkg/ the shared helpers. Storage is GORM, with drivers for MySQL and PostgreSQL in go.mod and a SQLite driver through glebarez/sqlite, which explains the changelog entries for TiDB support and database SSL configuration. Authentication runs on golang-jwt/jwt/v5, configuration is read through go-ini/ini from the conf/ directory, and scheduled work uses robfig/cron/v3, which is how the platform can send a hosted message on a schedule rather than only in reaction to an API call. The feature the README marks as recommended is templating: a message is defined once with placeholders and reused, so the same body can be pushed to several channels. Templates also gained a copy operation that brings the associated instances along, and hosted messages can be previewed asynchronously through a link.

Building the image and running it as one binary

The Dockerfile is a four stage build that produces a single artifact. A node:20-alpine stage builds the web console, the golang:alpine stage compiles the backend with the frontend output copied in for embedding, and an alpine:3.21 runtime stage carries the finished binary. The Go build is cross compiled with CGO disabled and the frontend assets embedded into the binary, which is why the runtime image needs nothing but certificates and timezone data:

FROM alpine:3.21 AS runtime-base
ENV TZ=Asia/Shanghai

The final image exposes a single port and starts the compiled program:

EXPOSE 8000
CMD ["/app/Message-Nest"]

The module declares Go 1.26.0 and the module name is message-nest:

module message-nest
go 1.26.0

For local work the Makefile runs two processes at once, a backend reload through air and the frontend dev server through npm, with the dev-backend target invoking go tool air and the dev-frontend target running npm run dev inside web/. The .air.toml file at the root configures that reload loop. Images are published under the engigu/message-nest name on GitHub Container Registry and Docker Hub.

Logs stay in the console, which is the sharpest edge here

The README contains an admission that deserves more attention than it gets. Considering that most services today collect console output, the project temporarily does not support writing log files. That is a real operational constraint. If you run Message Nest with Docker and redirect output to a file, you are building your own log shipping, and you have no application level log file to tail, rotate or ship. The same paragraph recommends the author's other project, a scheduled task execution panel called baihu, which points at a broader ambition: Message Nest is intended to sit inside a small personal or team infrastructure with other utilities around it. The demo site also gets an apology in the README for its slow server, which is a fair signal about what to expect from a project that is not a commercial product.

What each channel adapter costs you in configuration

Channel support is not free. Every adapter in go.mod pulls in its own client library: the Aliyun SDK for SMS, silenceper/wechat for WeCom, gomail for email, and the DingTalk and Telegram integrations sit alongside them. A channel needs credentials and endpoint configuration entered through the console before it can be used, and the 2026.01.14 changelog entry shows that even the Telegram bot adapter took care over proxy support, including HTTP and SOCKS5 proxies for users behind restricted networks. The 2026.06.03 entry added a push SDK API and Gotify and Ntfy adapters, and 2026.06.18 improved the template page so that copying a template also copies its associated instances. In other words, adding a channel is a recurring task in this project, not a one time setup, and the channel list is the thing most likely to change under you as vendors change their bot APIs.

Compared with calling each channel API from your own code

The alternative is to keep doing what the author was doing: a small function in each project that speaks to one or two channels directly. The difference in approach is architectural rather than feature by feature. Direct calls mean no central configuration, no secret storage to protect, no extra process to keep alive, and no dependency when the channel provider changes, because you own the client code and can patch it. What they cost is duplication, and duplication is exactly what breaks when a new channel appears or a bot token expires in one project but not another. A hub inverts that. It becomes the single place where a DingTalk webhook URL or an SMTP password lives, and every project talks to one local endpoint instead of to the internet. The hub is also where the templating and cron features live, since neither makes sense in a copy of a send function. If you have one project and one channel, the hub is overhead; with four projects and three channels, the duplicated function is the thing that hurts.

Apache-2.0 with a mandatory attribution clause

The licence is Apache-2.0, and the repository carries both a LICENSE file and a NOTICE file. The README states a mandatory requirement: any use, secondary development, modification or distribution must prominently credit the author engigu and keep the original repository link, with the details in NOTICE. That is narrower and more prescriptive than the plain Apache-2.0 text, so treat the NOTICE file as part of the licence rather than as a courtesy, and have it reviewed before you ship a modified build internally. On maintenance, the pace is fast: the last push was on 2026-10-22, with v2.3.0 published on 2026-10-17, v2.2.9 on 2026-10-16 and v2.2.8 on 2026-10-13. Three releases in four days means an active project, and it also means your pinned version will age fast, so the upgrade path between minor versions is worth reading in the changelog at engigu.github.io/Message-Push-Nest/guide/changelog.html before you jump.

Editorial conclusion

Message Nest fits a team that already talks to half a dozen messaging channels and keeps copying the same sending code into every script, because it replaces that code with one endpoint and a channel configuration table. Skip it for a single project with one channel, where a direct API call is shorter than a deployment, and skip it if you need durable log files, because the README states that writing logs to a file is not supported yet. Before adopting, read NOTICE, which requires attribution to engigu and the original repository link in any use or redistribution, and check the channel you rely on against the documented list before you wire it into a production script.

Frequently asked questions

Official sources

1. engigu/Message-Push-Nest on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases