Init.sh / Container Lifecycle Questions


#1

Hey folks, I’ve been digging into a glitch / ghost blog setup and picked up a few questions along the way about how instantiation for project containers works and / or best practices for getting more advanced. I’m thinking about writing a small guide so I wanted to get the right answers for these things:

Container lifecycle:

  • I gather that init.sh is run when the container starts up. Since things are backed by git, I imagine there’s a checkout step, then init.sh. What else happens during startup? Any way to tie into container shutdown?

Persistent data:

  • Since everything is backed by git, does that mean I can safely change and commit files using the command line? Any gotchas or subtly different behavior than normal git? What happens to uncommitted changes when a container shuts down?
  • Since everything can be remixed, best practices for non-remixable data is keeping things in .env (totally private) or .data (not remixed but not private)?
  • I’ve seen the warning that persistent data should be in .data, I’m guessing this is mostly for app-level data that isn’t git-friendly. When is this added to the container? Sort of related to my lifecycle question above.

That’s probably enough to start. I’ll keep digging around for answers.


#2

The primary source of truth isn’t Git, it’s the disk volume for your project that we mount at /app. We don’t do anything with git right now at startup. We do run pnpm to make sure your packages are installed, and then run your start command.

You can handle the shutdown event: End execution signal

The git repo is perfectly normal - it’s in the .git directory in your volume, and you can do anything you like with it. The only thing that’s unusual about it is that we commit to it periodically and as the container is shutting down.

Non-members can’t see the values in .env or files in .data. You can keep persistent data wherever you like, but we recommend .data because of the protection from non-members and because it’s already .gitignored.


#3

Oh, I see. init.sh isn’t something special for the container, it’s just run every time because the app start script includes bash init.sh.

Good to know that shutdown tip. Thanks!