I think we owe an equally proportionate measure of respect to the authors of boring old sqlite who, given the depth of their experience, recognize that there may in fact be benefits to be gained from the rewrite and are open to exploring the possibility. The blockers as stated, I have no doubt, were carefully considered with a level of insight few of us could match. If and when the time is right, if they choose to undertake the effort I'm sure the juice will be worth the squeeze. The fact that they're not jumping in blindly today is telling. Even more telling will be if they do eventually go that route.
I, like I assume everyone else who read this article, was interested in Render so I clicked through and started perusing the docs. I don't understand at all how secrets are meant to be managed by secret files when deploying docker containers. The secret sauce (haha) of secret files is that they don't survive the layer they're used in. How is that going to help at runtime? For accessing private repos to compile your go app in a build layer, sure. Hitting the DB or another API with a bearer token though? Seems like a non-starter. The docs even reference this
> Unlike build args, secret mounts aren’t persisted in your built image.
The doc you saw refers only to how secret files are treated at build time.
At runtime, Render mounts your secret file at `/etc/secrets/FILENAME` in your container. Your application can then read it like any other file on the local filesystem.
Of course, you can always store your secrets in Render environment variables and use them via ENV statements at runtime.
