Documentation

menu
Nix FlakesHostingIntroductionBranch HostingPull-request DeploymentsSecretsPersistenceDebuggingMultiple ServersCustom DomainsExample: Typescript & GoExample: JitsiExample: RSS BridgeExample: Tiny Tiny RSSExample: SearxGarnyaml configWhat Garnix CI doesIncremental BuildsUsing Private InputsCachingGitHub Actions IntegrationBadges

Persistenceshare

By default garnix will provision a new server on each deployment. This has the advantage of enabling zero-downtime deployments, as well as easy rollbacks and safe debugging (see below).

The disadvantage, however, is that any changes to disk are lost between deployments. This makes it unsuitable for persistence (e.g., databases).

For the latter, you have two options:

  • Using an external service, such as Supabase, Neon, or Xata.
  • Setting garnix.server.persistence.enable to true in your configuration after importing nixosModules.garnix from garnix-lib, and setting a garnix.server.persistence.name.

With this second option, garnix will redeploy new versions to the same server (i.e., one with the same garnix.server.persistence.name), if there is one. This enables you to keep data between builds.

Note that keeping your data safe, with backups and, potentially, failovers, is your responsibility. In fact, like hosting as a whole, persistence is in beta, so be particularly careful to have backups of anything you care about.