If we have the latest version the server knows about (from a previous request), we could even enrich with the full diff immediately. The app server can then contain the custom logic instead of the pds.

What about option 1 but add an option to the rpc lexicon declaring the pds should forward the current repo revision (so the server can fetch missing posts) as part of getPostThread.

Which part would you want terraform for? Setting up the server or setting up a repository, i.e. an account on a PDS server? Setting up a server is harder, I think. Setting up an account could work but given you often need a token sent by mail, I doubt you can do it with just a terraform provider.

Yes! I thought about adding that one as well but I guess that requires having a rotationKey so you can sign your operations without needing the security token sent by mail?

As Terraform announces new features like "actions" or "provider-defined functions", you'll understand them in no time with your increased understanding of how Terraform works and how providers work.

This course can also be useful if you just want a better grasp of how Terraform works under the hood. By building a provider from scratch, you learn all the details of how Terraform works and it will make you a better Terraform practitioner.

If you also want to learn how to write Terraform providers in your favorite language, you can follow my course.

But also for services, sync some records to your PDS while deploying, an alternative to the embedded PDS option that streamplace has chosen

An status page based on atproto?

In the end, with self-serving teams, application developers *need* to know Terraform.

This is the perfect course for you. You just get to build an application and don't have to care about Infrastructure at all. And in the end, you happen to master Terraform, while you just did what you love...