This is how I currently think this project can grow. Things can always change, of course, but I think it's good to have some direction, so here it is!

1. Make sure to have enough info to start the project, and get the word out
   • Strategy for setting up the instances
   • Getting a first website thingy
   • Getting accounts up for communication
   • Getting accounts up for donation
2. Host instances with custom domain and do proper set up
   • Start with cheap small server, enough to host one or two instances
   • Setup
   • Backup
   • Basic monitoring
   • Most can still be manual
3. Start improving where it makes sense
   • Automation of various tasks
   • Custom status 500 page
     • Link to hosting@ilja.space account (should announce down times)
     • Maybe auto refresh every 10 seconds or so
   • Retry for status 200 on the reverse proxy
     • https://til.simonwillison.net/caddy/pause-retry-traffic
     • https://caddyserver.com/docs/caddyfile/directives/reverse_proxy#lb_try_duration
     • Beware, by default only GET requests are done
     • Maybe consider adding this as an option in the Akkome Caddy example file
     • Should at least cover
       • a container restart.
       • Maybe enough for a quick (scripted) upgrade
       • If running from source, at least a restart after config change.
       • But also not too long. No idea what “too long” is, though.
   • better monitoring
     • Possible tools (but I should ask around as I don't have experience with them)
       • Grafana
       • Prometheus
       • …
     • What to monitor:
       • Total cpu/ram/disk
       • Postgresql (idk what can be monitored, but I guess cpu, ram, and maybe long queries)
       • Total ram of each instance
       • Also have alerting through e.g. email (getting notified via fedi would be even better)
   • Package Akkoma for Alpine so I can `apk install akkoma caddy` and `apk update && apk upgrade`
     • How does packaging work on Alpine?
     • How/where to host the package?
     • I need a test instance to test the package first
     • Do I need a CI to build the package, or do I do it manually?
     • Can I make sure that the update only happens when the correct Alpine version is installed? (I assume this happens with setting correct dependencies)
   • …
4. When we can afford it, get a proper domain
   • I would at least be able to cover 6 months of server (or other?) costs an one year of domain renewal before doing this
   • Add the option for (free of charge) subdomains
   • “Rebrand” this project
   • Move site under the new root domain
   • Start considering if it can be added to the Akkoma docs as an installation option
5. When we can afford it, get an extra server for other things than instances
   • Move the site away from the ilja.space server
   • Maybe also move mail
   • Move monitoring tools
   • Maybe think about extra's that can be useful, like a hosted LibreTranslate who can be set by default
6. If we have server space to spare, see if it can be useful for Foundkey/Akkoma related (or otherwise useful) stuff
   • Can be limited in cpu such that it can use resources when available, but gives priority to the hosted instances when they need it
   • Build server
   • CI server
   • Demo instance (e.g. similar to https://demo.mobilizon.org) turns out this already exists! https://otp.akkoma.dev
   • Ynh test env + Akkoma package (ofc, this also implies extra work for maintaining the package) already exists https://github.com/YunoHost-Apps/akkoma_ynh
7. If we have money to spare, see where it can be useful
   • Donations
     • Akkoma
     • Donations for Akkoma/Foundkey services
       • IRC, akkoma.dev…
     • Other things this projects uses
     • Other fedi projects
   • Pay devs to fix specific issues
   • Maybe think about paying work hours spend on running/maintaining this thingy
   • …
8. Maybe start thinking about setting up a legal entity and see if we can get more people do work coop style