forms.digitale-gesellschaft.ch

This repository contains code and configuration related to Digitale Gesellschaft's survey tool available under forms.digitale-gesellschaft.ch.

We rely on Formbricks which we host on Fly.

Sensitive configuration data is stored via Fly secrets. Currently this includes the following environment variables:

• CRON_SECRET¹
• DATABASE_URL
• ENCRYPTION_KEY²
• NEXTAUTH_SECRET³
• REDIS_URL
• S3_ACCESS_KEY
• S3_SECRET_KEY
• SMTP_PASSWORD
• SMTP_USER

Hosting details

• The Fly app is named digiges-forms, currently runs on a single shared-cpu-1x instance with 512 MB RAM⁴ and is hosted in the Frankfurt, Germany (fra) region.

• The digiges-forms app connects to the formbricks PostgreSQL database on our pg-digiges Aiven service hosted on DigitalOcean in the Frankfurt, Germany (fra) region.

  Note that Aiven's Postgres cluster TLS certificates are signed by its own private CA, so we have to manually specify the right certificate file when connecting, e.g.:

  PGSSLROOTCERT=aiven.io_ca.pem psql --dbname=$(grep -Po "(?<=^DATABASE_URL=').+(?='$)" .secrets)

• Formbricks requires a Redis-compatible key value store, even for a single-machine deployment. We use Valkey, managed by Aiven as service valkey-digiges, hosted on DigitalOcean in the Frankfurt, Germany (fra) region.

• Formbricks also requires an S3-compatible⁵ object storage bucket to store static user file uploads. We use a Tigris bucket named digiges-forms attached to our Fly app.

• To cope with higher demand when conducting surveys, we can increase RAM and/or switch to a faster CPU as needed⁶. It's recommended to allocate at least 1024 MB RAM before running any serious survey.

  We could also scale horizontally, i.e. run multiple instances of Formbricks, even in multiple regions.

Admin access

We can directly connect to the digiges-forms app via an SSH tunnel to perform any low-level administration tasks. To do so, run:

flyctl ssh console --app digiges-forms

Deploy new Formbricks release

To deploy a new digiges-forms release on Fly, follow these steps:

1. Create a local snapshot of the database, see below.

2. Set the desired ghcr.io/formbricks/formbricks tag in the Dockerfile.

3. Update the Formbricks configuration in fly.toml's [env] section and -- for sensitive information -- in the app's Fly secrets if necessary.

   Documentation of all the environment variables Formbricks supports for configuration should be found in the docs. If something is missing, the following resources should help:

   • File turbo.json lists all supported env vars without further info. Use GitHub's compare view to compare the desired formbricks release tag with the one that is currently deployed. To e.g. show the diffs between version 4.0.0 and 4.0.1, use https://github.com/formbricks/formbricks/compare/4.0.0...4.0.1#files_bucket.
   • File .env.example contains example configuration.

4. Build and deploy the image:

   just deploy

5. Consult the official migration guide. For Formbricks 4.x and above, all database migrations should be done automatically without any further action necessary.

Back up PostgreSQL DB

To create a full dump of the formbricks PostgreSQL database, run the following:

just backup

(You need the Git-ignored .secrets file for the above to work.)

Restore PostgreSQL DB

To restore the formbricks PostgreSQL database from the latest local dump created via just backup, run the following:

just restore

Alternatively, you can restore an explicit dump via the recipe's datetime parameter:

just restore '2025-11-11T04:20:49+01:00'

(You need the Git-ignored .secrets file for the above to work.)

License

Code and configuration in this repository are licensed under AGPL-3.0-or-later. See LICENSE.md.

Footnotes

1. Mustn't exceed 256 bits / 32 bytes in binary representation. ↩

2. Mustn't exceed 256 bits / 32 bytes in binary representation. ↩

3. Mustn't exceed 256 bits / 32 bytes in binary representation. ↩

4. Especially the first start after a new deployment turned out to be memory-intensive (probably the Prisma Client performing the DB migrations): With 256 MiB RAM, the app used to crash reproducibly, so we increased this to 512 MiB. ↩

5. Note that we can't use Backblaze B2 since its S3-compatible API doesn't implement the POST Object operation that Formbricks uses to upload files. ↩

6. Note that scaling automatically restarts the app. The most relevant documentation on (auto)scaling Fly apps includes:

   • Scale Machine CPU and RAM
   • Scale the Number of Machines
   • Automatically Stop and Start Machines
   ↩