Start-up and installation errors

Problems that appear when the application starts, or when it is first installed.

The installation page appears again

GrandNode shows the installer when it finds no database settings. The connection string is stored in App_Data/Settings.cfg, written by the wizard. If you redeployed the application without that file - a new container, a fresh folder - the installer appears. Restore Settings.cfg instead of installing again over a live database - or, better in containers, pass the connection string as the environment variable ConnectionStrings__Mongodb, which takes precedence over the file. The same applies to InstalledPlugins.cfg: if it is lost, the store starts without its plugins. See Running in production: Docker and Kubernetes.

"The database version is not supported in this software version"

The application checks that the database version stamp matches what it supports. On an upgrade, migrations update the stamp automatically when the application starts. You see this message when:

  • the database is newer than the application - for example after rolling back the code without restoring the database;
  • the upgrade migrations failed - check the log of the first start after the upgrade.

Run the GrandNode version that matches the database, or restore the database backup taken before the upgrade. Always back up before upgrading.

MongoDB connection errors

  • Check the connection string in Settings.cfg: host, port, database name, user, and authSource when the user is defined in another database.
  • In Docker, the host is the service name of the MongoDB container, not localhost.
  • Firewalls and MongoDB's bindIp must allow the application server.

Wrong URLs or redirect loops behind a proxy

Behind a reverse proxy, load balancer or Kubernetes ingress that terminates HTTPS, the application sees plain HTTP. Links then use http://, or HTTPS redirects loop. Set Security:UseForwardedHeaders to true (the proxy must send X-Forwarded-Proto and X-Forwarded-For), or Security:ForceUseHTTPS. The store URL in Configuration → Stores must be the public HTTPS address.

The first request is slow

After a start, the first requests load plugins, compile views and fill the cache. It is normal for them to take several seconds. A health-check or warm-up request after deployment hides this from customers.

Question not answered here? Ask the community on GitHub Discussions ↗