Translators
It looks like 2-3 days for a working prototype, 4+ updates per year.
@nebulon Woohoo! Every first Monday of the month at 12:30 PM for the Mautic meetup works with Thunderbird. Great job!
I packaged Readeck as community app: https://ca.cloudron.io/app/readeck
Running an alternate mail server on Cloudron is unlikely. Automated provisioning of email setup of apps is part of the product (from v1 of Cloudron) and this would break if we supported other mail servers.
@fbartels not yet, but we can possibly add routing options as we go. Do we have concrete use cases? Maybe we should collect them and decide what is the best approach. I know "always bcc" is something people have wanted but the real use case here is to have an archive of email for regulatory purposes.
I just wanna share my experiment to install sGTM on Cloudron.
And I think it works well, and I got this code from Claude AI.
You can use this CloudronManifest.json and execute it via Cloudron CLI:
And my question is how to make the update process automatically from Cloudron dashboard?
Thank you.
{
"id": "com.example.sgtm",
"title": "Server-side GTM",
"author": "Admin",
"description": "Google server-side Tag Manager (sGTM) tagging server, packaged for Cloudron.",
"tagline": "Self-hosted sGTM tagging server",
"version": "1.0.4",
"dockerImage": "gcr.io/cloud-tagging-10302018/gtm-cloud-image@sha256:688d35c6c54473be42d5128befa4d98a722d76d6fdf9cb84d63b52a3f223a1e6",
"healthCheckPath": "/healthz",
"httpPort": 8080,
"manifestVersion": 2,
"website": "https://services.example.com",
"contactEmail": "admin@example.com",
"tags": [
"analytics",
"gtm",
"tracking"
],
"memoryLimit": 1073741824,
"addons": {
"localstorage": {}
}
}
And this is the README.md:
This guide explains how to run the official Google image gcr.io/cloud-tagging-10302018/gtm-cloud-image as a custom Cloudron app, directly without building a Dockerfile. The image is pinned via the dockerImage field in CloudronManifest.json using an immutable digest (@sha256:...). There is no Dockerfile, and no build process is required.
You will run TWO apps from the same package:
| Role | Domain (REMEMBER!) | Required Environment Variables |
|---|---|---|
| Serving | services.example.com |
CONTAINER_CONFIG + PREVIEW_SERVER_URL (no RUN_AS_*) |
| Preview | service.example.com |
CONTAINER_CONFIG + RUN_AS_PREVIEW_SERVER=true |
️ Important: Naming Convention (Easy to mix up!)gtm.js️ Important: Docker Images (A hard-learned lesson!):stable tag in dockerImage. Cloudron/Docker caches :stable to the old digest. This means an update might report as "successful," but the old version will still be running (e.g., sticking to 4.3.0 instead of 4.4.0). Using --no-cache DOES NOT help here—that's a build-cache flag, not a pull-cache flag, and this setup doesn't use builds anyway.@sha256:...). It is immutable and content-addressed, making it impossible to cache incorrectly. Explicit version tags (e.g., :4.4.0) are also safe; only :stable (and :latest) are dangerous because they are mutable.dockerfileName: null in the app config is the correct approach./gtm.js (NOT /load)The server only serves the default /gtm.js path. Custom paths like /load WILL NOT work (returning a 400/Not Found error). In your GTM "Web Container" client, it doesn't matter if you fill the Tag serving path with /load or leave it empty—it won't affect anything, as the server will always use the default /gtm.js.
The first-party URL used by your site (via GTM4WP):
https://services.example.com/gtm.js?id=GTM-XXXXXXX
(The ?id= parameter is MANDATORY; without it, you will get an error, which is completely normal).
/gtm.js isn't working)Check the environment variables for both apps:
cloudron env list --app services.example.com
cloudron env list --app service.example.com
PRODUCTION (services) MUST HAVE:
CONTAINER_CONFIG = (your configuration string)PREVIEW_SERVER_URL = https://service.example.comRUN_AS_PREVIEW_SERVER variableIf your services app was accidentally set as preview, fix it:
cloudron env unset --app services.example.com RUN_AS_PREVIEW_SERVER
cloudron env set --app services.example.com PREVIEW_SERVER_URL='https://service.example.com'
cloudron restart --app services.example.com
PREVIEW (service) MUST HAVE:
CONTAINER_CONFIG = (your configuration string)RUN_AS_PREVIEW_SERVER = trueTest it: Visit https://services.example.com/gtm.js?id=GTM-XXXXXXX -> It should output JavaScript code.
NOTE: CONTAINER_CONFIG and sensitive tokens are NOT stored in this repository. Always set them via cloudron env set, keeping them out of Git.
Because the image is pinned via dockerImage (not a Dockerfile build), updating simply means changing the image reference in CloudronManifest.json and deploying. You DO NOT need --no-cache, and there is no Dockerfile to edit.
Steps:
Find the latest version & digest:
gtm-cloud-image (project cloud-tagging-10302018, repo gcr.io), and open the Overview tab.4.5.0). Copy the "Digest" value (sha256:...) from the version that also holds the stable tag.Edit CloudronManifest.json:
version (e.g., 1.0.3 -> 1.0.4) — MUST be increased with every update.dockerImage to the new digest:"gcr.io/cloud-tagging-10302018/gtm-cloud-image@sha256:<NEW_DIGEST>"...gtm-cloud-image:4.5.0)Commit & push to your Git repository.
Deploy BOTH apps from the repo folder (from any machine with the Cloudron CLI installed):
git clone https://git.example.com/username/sgtm-cloudron.git # first time only
cd sgtm-cloudron
git pull # if already cloned
cloudron update --app services.example.com # PRODUCTION
cloudron update --app service.example.com # PREVIEW
Cloudron will read the dockerImage from the local manifest and pull that image directly. A different digest equals a different image, guaranteeing a fresh pull.
Quick Alternative without editing the manifest (Ad-hoc):
This is valid but leaves your repo out-of-sync with what's actually running. If you use this, please update your manifest afterward!
cloudron update --app services.example.com --image gcr.io/cloud-tagging-10302018/gtm-cloud-image@sha256:<DIGEST>
cloudron update --app service.example.com --image gcr.io/cloud-tagging-10302018/gtm-cloud-image@sha256:<DIGEST>
Verification:
https://services.example.com/healthz -> Should return OKhttps://services.example.com/gtm.js?id=GTM-XXXXXXX -> Should still return JS codeUpdate downtime is just a few seconds and WILL NOT affect your site.
The image consists of Node.js + libraries. Google releases periodic security patches. Because this is self-hosted, keeping it updated is your responsibility.
Note: The enableAutomaticUpdate feature in Cloudron DOES NOT pull new Google versions on its own—it's only for package versions we publish. Google version updates are always manual via Section 2.
CloudronManifest.json: App metadata + pinned image via dockerImage (digest). This is the SOURCE OF TRUTH for the running version.README.md: This file.If I use this MCP, can I update several apps in just one-command?
girish said:
mail: fix mail forwarding. there's been lots of bug reports on this feature. have to investigate the root cause
The mailing list feature has got a revamp. For a start, it's completely removed and all the lists will be migrated to a mailbox with the Cloudron superadmin as the owner.
Each mailbox now has a capability to set up forwarding (same options as mailing list):
For the delivery aspect:
Unfortunately, there is nothing much we can do here about the delivery aspect. If it works, it works.
I really like the instance locking workflow at Hetzner. A small lock icon button helps users avoid accidentally deleting a VPS. It might be a good idea to adopt this for Cloudron apps. When you want to delete an app, you have to confirm a dialog (usually you have to re-type the app's name or domain). While it's annoying in everyday use, it saves your ass when you're working late at night.
|
159
Posts
129
Reputation
|
|
1
Posts
2
Reputation
|
|
66
Posts
76
Reputation
|
