Deployment principles #10
aerugo
announced in
Announcements
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
As we start planning for making the app interactive, we have defined some principles for how it should be built and deployed.
Project deployment principles
One deployment per project. Building multi-tenant apps and SaaS is complicated. We will build an app that has one deployment per project. Our focus is on making the best experimental collaborative writing and annotation app we can, and we would be seriously encumbered by also making it a service.
Deployment should be easy. To lower the complexity of setting up the app, we will assume that most deployments will do fine on off-the-shelf "hobby level" cloud services. It will probably be rare for a project to have more than a handful of contributors as this app is meant to enable a defined group to write and annotate together.
Off-the-shelf cloud services with generous free tiers for key infrastructure. To avoid requiring self-hosted auth, databases, and mail servers, we will use cloud services for these needs. These have the drawback of being expensive in production for most projects, but since we don't expect more than a handful of contributors per project, the free tiers of services like Auth0, Neo4j Aura, and Mailgun will be enough for the vast majority of cases. If we build the API and UI to be hostable on services like Vercel, it might even be possible for most users to run the app without any cost at all, and without ever having to see a terminal.
Beta Was this translation helpful? Give feedback.
All reactions