do you have a recommendation for the RAM on the server ? We hit 1Go yesterday, so we now have passed to 2Go, FYI.
do you think it’s possible to have multiple containers running in parallel (i.e. is a running Grist stateless) ? Would that need using PostgreSQL for the “core” db ?
It is indeed possible to have multiple containers in parallel - we do so in our hosted service - but there’s significant engineering work needed to make this happen. In general for a single organization I’d expect one server with more CPU and RAM to be preferable to multiple lighter servers.
The original version of the instructions above, combined with a version of grist-core up until v1.1.7, produced an insecure configuration which made it possible for an attacker to impersonate any user on the system.
Please be sure to update grist-core and/or the gristlabs/grist docker image to the latest fixed version (v1.1.8, stable, or main).
This alert also applies to grist-omnibus (docker image gristlabs/grist-omnibus). Upgrading to the latest version will fix the issue.
The issue affected specifically the suggested configuration of grist-core with traefik. If you used a different configuration, you may not be affected.
This should get everyone started with a Grist instance behind Traefik. Ping me, if you have any questions or comments.
I’m posting this now, because I have just come up with this healthcheck: for the Grist container. This or something similar could also be added to the Dockerfile as a HEALTHCHECK line, in so all container schedulers can benefit from it’s presence. The easiest would probably to also add a minor curl dependency on the final container image and check the status code of the /api/orgs route (the only one without parameters) with it instead of this Python one-liner construct.
I see GRIST_SANDBOX_FLAVOR=unsandboxed in there which is reasonable if you trust all documents (glad to see GRIST_ANON_PLAYGROUND=false) otherwise it could be dangerous. The options gvisor or pyodide offer some sandboxing of user Python code.
There is also an undocumented /status endpoint for the purpose of healthchecks.
Adding curl into the image would be very reasonable - we would accept a pull request for that, otherwise I expect we’ll get to this eventually.
Many thanks for the review and comment on security implications especially.
I’m having many tabs open with Grist at the moment, thanks to your casual reminders that community contributions are accepted. Will be happy to pick up some of the loose ends nearing winter.