NetSendo v2.3.1: Faster Cloud Updates After Each Release

When you run your marketing on a hosted platform, the time between "a fix is released" and "the fix is running on my instance" matters. This is especially true when the fix closes a security hole. Until now, NetSendo Cloud instances found new versions through the hosting provider's nightly registry check. So a release could sit unused for up to a day before the update process even saw it.

NetSendo v2.3.1 removes that wait. When a new version's Docker image is published, the release pipeline sends a signed notice to the NetSendo Cloud catalog right away. Hosted instances learn about the new version immediately, and urgent security releases are installed straight away.

🚀 What's New in v2.3.1

From "we'll check tonight" to "here's the new version"

Think of the old process like checking your mailbox once a night. A letter might arrive in the morning, but nobody opens the box until evening. The new process works like a doorbell. As soon as a release is ready, Aderlo's catalog is told about it.

Here's how it works:

1. A new version tag (vX.Y.Z) is pushed to the NetSendo repository.
2. The workflow in .github/workflows/docker-publish.yml builds and publishes the Docker image.
3. After the image is published, the workflow sends a signed call to Aderlo's release catalog.
4. The catalog records the new version, and NetSendo Cloud instances are scheduled for the update.

Two rollout paths

Once the catalog knows about a release, the update takes one of two paths:

• ✅ Standard releases are installed on hosted instances one group at a time, at night. This keeps disruption low and limits the impact if something unexpected comes up.
• ✅ Security releases are releases whose notes include a ### Security section. They're installed at once, without waiting for the night window.

Here's an example of release notes that would use the fast lane:

## v2.3.2

### Security

- Fixed an authorization check in ...

### Fixed

- ...

⚠️ Important: A ### Security section causes immediate installation on NetSendo Cloud. Use it only for vulnerability fixes. Put hardening ideas, dependency bumps without a known vulnerability, and general improvements under ### Changed or ### Fixed.

A key with one job

The call to Aderlo is signed with a secret stored as ADERLO_RELEASE_KEY in the repository's GitHub Actions secrets. This key is limited on purpose: it can only refresh the catalog. It can't access customer instances or customer data. This follows the principle of least privilege. If a credential leaks, it should do as little damage as possible.

ℹ️ Note: This change applies only to NetSendo Cloud, which Aderlo hosts. Self-hosted installations are not affected. You still decide when to pull and deploy new versions.

💼 Benefits & Use Cases

🛠️ Step-by-Step: What You Need to Do

If you use NetSendo Cloud

1. Nothing to configure

   Updates are scheduled automatically once a release image is published.

2. Expect night-time updates

   Standard releases arrive during the night window, one group of instances at a time.

3. Watch the release notes

   Read the GitHub releases to see what changed. Security releases may arrive outside the night window.

If you self-host NetSendo

Your setup doesn't change. Pull new versions when you're ready, for example:

docker compose pull
docker compose up -d

Check our documentation for the full upgrade procedure for your deployment.

If you contribute to or maintain NetSendo

1. Tag releases as vX.Y.Z

   The Cloud notice is sent after the image for a version tag is published.

2. Reserve ### Security for vulnerabilities

   This heading means "install everywhere right now." Don't use it for other changes.

3. Treat ADERLO_RELEASE_KEY as a secret

   Keep it in GitHub Actions secrets only. Never print it in logs or commit it to the repository.

💡 Common pitfall: Adding a ### Security heading "just in case" skips the staged night rollout for every hosted instance. If you're not sure whether a change fixes a vulnerability, leave it in the standard flow.

🏁 Conclusion

v2.3.1 is a small change to the release pipeline, but it helps every NetSendo Cloud customer. New versions no longer wait for a nightly registry check. Regular updates go out to hosted instances one group at a time, at night, and security fixes are installed at once. The signing key can only refresh the catalog, and self-hosted installations keep working as before.

Self-hosted users still decide when to update, and Cloud users now get updates sooner.