Cloudron Forum

Latest update works! Thanks for the fixes.

I'm going to play with it for a bit but I'll leave a few more things I noticed in case you want to address those too:

• If you do git add --chmod=+x cld.sh locally you can then commit the executable flag with your repo and skip a step in the README.
• The cld.sh script should probably have a set -e line at the top (after the #!/bin/bash) to make sure the script stop executing if something goes wrong with one of the commands.
• Currently everything in /app/data is owned by root and I believe agate itself is launched as a root owned app. It's probably safer to make all the files in in /app/data owned by cloudron:cloudron and launch programs with /usr/local/bin/gosu cloudron:cloudron to run as the cloudron user. I might be off here but that was my understanding of recommended behavior looking at the documentation. Someone else can deny or confirm.

Great job on the app!

Testing it now...

• You need a chmod +x cld.sh in the repo.
• The installation never completes for me. It gets stuck at Waiting for propagation of newsite.malenfant.dev even though the DNS is updated. The app doesn't seem to launch.

Could be something with the DNS on cloudflare... Log shows:

Jul 16 17:28:25 box:dns/waitfordns resolveIp: Checking A for newsite.malenfant.dev at 162.159.38.40
Jul 16 17:28:25 box:dns/waitfordns resolveIp: No A. Checking CNAME for newsite.malenfant.dev at 162.159.38.40
Jul 16 17:28:25 box:dns/waitfordns isChangeSynced: NS davina.ns.cloudflare.com (162.159.38.40) errored when resolve newsite.malenfant.dev (A): Error: queryCname ENODATA newsite.malenfant.dev

but if I ping newsite.malenfant.dev from the command line it gets resolved correctly... odd.

Could it be that the domain is hardcoded in cld.sh?

# Generate self-signed wildcard certificate for all subdomains
echo "Generating self-signed wildcard certificate for *.appx.uk..."
# Extract the base domain (appx.uk) from CLOUDRON_APP_DOMAIN
BASE_DOMAIN="appx.uk"
WILDCARD_DOMAIN="*.${BASE_DOMAIN}"

Nice one!

I think as an option it's a really good idea. I'll look into it if I get a chance.

@timconsidine said in Agate - A simple gemini server:

If it were built into your agate deployment, would that deliver an app which effectively serves both gemini and http ?

It looks like it could work. What I'm not sure is:

• How do we make it an option so that people who don't want http can have it off.
• It doesn't seem to return when launched so how do we run both this and agate side by side?
• How safe is the http server for this? The one I use for the health check, Caddy, is pretty well supported and widely used. I don't know about this one.

@LoudLemur said in Agate - A simple gemini server:

I think Agate supports multiple users, so that might end up with some confusion, too.

The way the app is setup in my case is just to serve files located in /app/data/public. You can see the default index.gmi in there after you install; the app. Editing this and setting up the folder structure is left to the user as it's basically gemini stuff and not specific to the app itself.

I'm going to update the README in the repo to mirror @timconsidine's great step by step instructions on installing the image.

@timconsidine said in Agate - A simple gemini server:

@LoudLemur try ….
cloudron install —image didiermalenfant/net.malenfant.agate:latest
In other words put a space not a colon after ‘image’

Yep, good catch. That's totally a typo on my part.

@LoudLemur said in Agate - A simple gemini server:

Move Agate to your Cloudron
It helps to have a GUI, so install the Cubby application on Cloudron.
Then, open Cubby's file browser and use it to upload the agate folder to an appropriate place (where?!) on your Cloudron.

Wait... I'm confused. Where are those steps from? The next step in my list above was to install the cloudron CLI.

@LoudLemur said in Agate - A simple gemini server:

What is the procedure to try and install this on Cloudron?

• Make sure your Cloudron backups are up to date
• Clone the app's repo from https://code.malenfant.net/didier/agate-app.git
• Install the cloudron CLI
• Login to your cloudron server
• CD into the cloned repo's folder
• Type cloudron install --image:didiermalenfant/net.malenfant.agate:latest
• Enter the subdomain you want to install the app at.

Let me know if you encounter any issues. This is pre-release software but it would be good to get feedback from other people too.

Ok the docker issue is on their end. I'll wait until tomorrow to clean all the images on my repo up.

I've posted about this app on the Wishlist section to see if there is any interest in putting in on the App Store.

• Title: Agate on Cloudron - A simple gemini server

• Main Page: https://github.com/mbrubeck/agate
• Git: https://code.malenfant.net/didier/agate-app
• Licence: MIT
• Docker: didiermalenfant/net.malenfant.agate:20250709-011124-02250deeb
• Demo: https://gemini.malenfant.net

• Summary: Allows users to install a gemini server on cloudron in one-click.

• Notes: I use Gemini for some different kind of content than I do on my regular blog. The crowd reading gemini 'capsules' (as they are known) is also very different from the main 'big' web. Kinda like Mastodon vs Twitter.
  This is my first cloudron app. I welcome all comments and help with fixes for things I got wrong.

@timconsidine said in Trying to package Agate - A Gemini server:

You're pushing the docker image to the repo ?

No, I meant pushing to docker hub. It looks like something is borked on my docker hub repo.

Tags page isn't updated anymore and doesn't reflect the images I've pushed to the repo. Tags can't be deleted in the hub, nothing happens. The repo itself can't be deleted, I get 'unable to delete repository'.

If your ambition is to have this considered for the AppStore here (good ambition, and I can see a use for it here), it would be good to have the repo on git.cloudron.io .

I read the docs and I think I have to post in the wish list category when I'm ready to take the next steps.

Little 0.3.1 update:

• docker image is now tagged by cloudron build
• info page for http requests now has a clickable link to the gemini site itself

I'm having trouble pushing the docker image to my repository when it's tagged with something like 20250708-205348-96303b94f. It does push the image but it doesn't show in the list of tags for the repo.

Wonder if I'm doing something wrong...

@robi said in Trying to package Agate - A Gemini server:

Are there any HTTP browsers that have added gemini support?

The problem is when you search for gemini plugin you get results for Google's AI stuff instead...

Just updated the app to 0.2.0.

• added some user-modifiable information about gemini when the app is accessed on the HTTP port
• user can now set a different port for the gemini server if they want
• removed an unnecessary mkdir in the Dockerfile

I'm going to dogfood it on my own server for a bit and then if everything looks good I will look into posting it to the App Store here.

I use Lagrange too. My main capsule (as they are known) is at gemini://gemini.malenfant.net

To answer your question, it's a bit of a throwback to simpler times. I post different things on my gemini site sometimes, the crowd reading it is different too. A bit like Twitter vs Mastodon kinda thing.

Oh man... I found the bonehead mistake causing this... The gemini port is 1965 not 1950

After letting everything happily propagate, I now have a gemini server running on my test Cloudron at gemini://test.malenfant.dev... YAY!

I'm going to play with it for a bit. If someone with more experience than me could sanity check the Dockerfile, CloudronManifest.json and start.sh to make sure I'm not doing anything stupid then I can make this a 1.0.0 version.

This is my first foray into Cloudron app packaging, please be kind

I decided to try and package Agate which is a simple Gemini server.

I've published the repo and the image online.

Agate listens on port 1950 which is a standard Gemini port so I used Caddy to respond to Cloudron's health check and I added a tcpPort in the manifest for port 1950.

Running the docker imager locally (without Cloudron) seems to work ok. I map /app/data to a local folder, define CLOUDRON_APP_DOMAIN to 'localhost' and map ports 80 and 1950 to my local host. I can then see the response on port 80 and the Gemini page when browsing localhost with Lagrange.

When installing the image on my test server the http port works fine and serves the http response but port 1950 doesn't seem to be forwarded to the container when browsing with Lagrange.

Anything obvious I'm getting wrong here?

Thanks! I'm going to play around by modifying an existing app and see how far I get.

That great. I can probably take a look at those as a starting point.

Does a Cloudron app need to do anything web-facing wise or could it just be a container running and doing nothing until you log onto it?