Ops for clojars is basically just me. It all runs in AWS, and we use terraform to manage it. There is one server instance and one db instance. The server instance is ephemeral, and I build and switch to a new AMI every few weeks to get the latest security updates. Happy to chat more about this/how we can make this easier for cljdoc. See for that code/docs: https://github.com/clojars/clojars-server-config

Nice, that sounds good! cljdoc is running on sqlite which makes the ephemeral instance approach a bit hard but I guess it wouldn’t be hard to swap that for postgres or something

Yeah, moving to an ephemeral instance is what motivated the move from sqlite to postgres for clojars. Alternatively, you could copy the sqlite db to s3 after every write, but that feels excessive (unless the write volume is low)

I really mostly went with the nomad thing to have 0 downtime deployments (blue/green) with 1 instance

funnily enough write frequency is basically as often as people publish a new jar on clojars 😄

heh, that makes sense :)

The cljdoc infra is also already managed via Terraform but it’s very long-lived and I’ve been dreading the day I need to recreate the instance for a while lol

and one thing that was quite important to me was continuous deployment, e.g. if contributors merge a PR I don’t want to be blocking to get that live

Also using Packer for some basic stuff already, all the ops docs are https://github.com/cljdoc/cljdoc/tree/master/ops

> funnily enough write frequency is basically as often as people publish a new jar on clojars Seems like a good example of real “RESTful” architecture that results in two related systems that logically share data “just working” together even though the two use completely different stacks and have completely independent deployment pipelines. If only most companies’ systems were so well decoupled.

good point @U065JNAN8!