Easy server setup for personal use

[djmitche]

At the moment, the most common use of this tool is as a server for one person's tasks, usually running on a VPS or other publicly-exposed server. I get the sense that a lot of folks are not using HTTPS, but if it was easy they probably would.

Let's optimize this use-case:

• Simple-to-deploy, such as in a docker image
• Disallow additional client-ids beyond the one
• Support TLS as easily as possible (ideally with letsencrypt?)

[Necior]

I like the idea of making self-hosting friendlier.

Support TLS as easily as possible (ideally with letsencrypt?)

As someone who's been self-hosting a lot of things for years I might be biased but I'd rather have TLS stuff outside of taskchampion-sync-server.

A common approach is to use a reverse proxy (e.g. Apache, Caddy or Nginx) in front of an application server. This has a few advantages:

• Using one with Certbot or cert-manager is battle-tested and well documented. Caddy even has automatic HTTPS.
• Only one place to configure certificates and their auto renewal. This is most helpful if one hosts other services next to taskchampion-sync-server.
• There is less to learn about hosting taskchampion-sync-server specifically.
• Less code in taskchampion-sync-server.

From my point of view, examples how to configure most popular HTTP servers to forward traffic to taskchampion-sync-server would be most helpful.

[ryneeverett]

I suspect there would be no objections to documenting more http servers but I think the goal of this issue is to reduce the amount of choice presented to users and give 'one good-enough option' to serve as both the easiest way to get started and a reference deployment.

I agree that it probably doesn't make sense to incorporate tls in taskchampion-sync-server though unless it's become substantially more trivial than last time I looked into it. Assuming we went the docker route, perhaps it would make more sense to present a docker-compose or kubernetes manifest to spin up a separate http server.

[djmitche]

Agreed, I was definitely not suggesting implementing TLS in the Rust code, but building something wrapping nginx and taskchampion-sync-server up in a nice easy-to-use bow. I think a lot of users aren't familiar with self-hosting, and probably don't want to learn anything new about nginx or cert-manager.

[djmitche]

@Necior do you think you could work something up, maybe a docker image or a docker-compose script? I imagine it would take a few env-var configs (like the hostname and port) and mount a few directories (for task data, tls metadata storage, etc.) but otherwise be pretty much hands-off.

[Necior]

I think the goal of this issue is to reduce the amount of choice presented to users and give 'one good-enough option' to serve as both the easiest way to get started and a reference deployment

I initially understood the issue differently but what you're saying makes more sense.

@Necior do you think you could work something up

I'm not able to take this on right now.

---

What would a great user journey look like? Is there prior art, so to speak?

I checked a few other projects that people self-host:

• Immich: recommends Docker Compose and setting up a reverse proxy for TLS. Their documentation points to a community run all-in-one container but it doesn't handle certificates;
• Photoprism: provides examples of using different reverse proxies. There is a way to bring your own certificate to Photoprism but its generation and renewal is out of scope;
• Forgejo: similar approach to Photoprism;
• Grafana: documents how to use it with certbot.

[djmitche]

I'm not able to take this on right now.

I appreciate this!

What would a great user journey look like?

Good question -- in an ideal world, the fix would be a single command with some substitutions in it that users run and the server is up and going. But that these other examples don't do that suggests it's probably hard!

Taskwarrior has the advantage of a pretty technical userbase, so instructions like those you've linked to are a good choice, too.

I think the Grafana solution is the closest, and AIUI that relies on certbot to schedule the refreshes. We could probably do something similar.

[Necior]

(A stream of thought below, hopefully mostly coherent.)

A simpler-to-use solution requires more assumptions about the environment of execution, compared to other approaches.

One way to to enable certificate (re)generation is to assume control over ports 80 and 443 on a server. Additionally, I believe it requires a public IP address.

Also, there is a need to run a certificate regeneration process every few months which either implies some kind of cron job or a mostly idling process that wakes up once in a while.

It could be either implemented as a (set of) container image(s), or as a VM image. I'm not sure what people would prefer. Containers seem more popular.

Maybe it would make sense to use something like Caddy. It would bind to ports 80 and 443, handle certificates and forward traffic to t-s-s.

Assuming the container route with Docker Compose, instructions for users would boil down to:

• install an OS that supports Docker Compose on your server;
• point example.com A/AAAA records to the server IP;
• set the domain name in configuration of Docker Compose;
• run Docker Compose;
• optionally configure custom storage directories, or restrict client ids, or other customization.

[djmitche]

That sounds like the right user journey!

[djmitche]

GothenburgBitFactory/taskwarrior#3709 is relevant here, too -- thanks @zilto!

[djmitche]

Take a look at #68, please?