twelve factor app

Great resource!

Write database migrations in both directions so people can downgrade on failures.

Good point. Personally, I take backups before upgrades and restore if anything goes wrong. But, I understand how downgrading sometimes is just easier.

I have trouble coming up with a migration procedure that makes sense to me. I have the following in mind:

1. Provide init scripts that produce a schema that matches beginning state of the current major.
2. Provide major to major migration scripts.
3. For every major, provide minor to minor migration scripts.
4. Schema changes require at least a minor release.

Make it possible to configure your system via ENV variables, ENV files and config files.

I am bit worried about this one, environment variables can be a security concern. Specifically, I am not sure if I should allow providing secrets (like db connection strings) through environment variables. I am inclined to let people do what they want to, but issue a warning.

Make it possible to disable authentication to add Authelia or LDAP through the webserver. Make clear that this is only to be used for external authentication.

I am considering adding support for oauth through keycloak. My assumption is that if you are going to host your own LDAP, you can probably configure keycloak too. Do you think that makes sense?

Make it possible to run multiple parallel instances of your software without affecting the database consistency, e.g. for high availability or horizontal scaling.

Ideally, an instance shouldn’t be big enough to need it. I know, famous last words, but in my case I think it’s a bad problem to have. I am going out of scope, but I am wondering where is the line between discouraging large scale deployments and designing something pre-destined to obscurity.

Telemetry

Not even on my radar, thanks for bringing it into my attention 🙏