Backup | Update | Install - Invoice Ninja - MGM CLI Script

Easily update, backup, and install your self-hosted Invoice Ninja instance with a CLI shell script.

I’ve developed a comprehensive bash CLI script to manage Invoice Ninja backups and updates directly from the command line. This script simplifies the process of updating and backing up your self-hosted Invoice Ninja instance. It automates all the intricate steps, allowing you to focus on more important tasks.

Key Features

  • Automated Updates: Downloads and installs the latest version.
  • Installations: Provisioned and clean options.
  • Efficient Backups: Manages backups with custom settings.
  • Maintenance Management: Handles maintenance mode, cache clearing, and more.
  • Post-Update Tasks: Includes data migration, optimization, and integrity checks.
  • Docker Friendly: Can be integrated in docker setups to deploy updates decoupled from webserver.

I’ve made an effort to document every aspect of the script to ensure that all questions are answered and to facilitate ease of use. The script is crafted from scratch, not just a one-liner.

:golf: Backup | Update | Install - Invoice Ninja - Shell Script

:arrow_forward: https://youtu.be/SdOmEkSL9os

4 Likes

Thank you, @dros!
Is there a way to use your script on a shared hosting without sudo rights?

There should be no need for sudo when you run it as the user with the rights that’s able to read the Invoice Ninja .env file. Also make sure you have set that particular user in the .inmanage/.env.inmanage file under INM_ENFORCED_USER … Let me know if it works.

Edit: I added a note into the documentation for this particular case.

1 Like

Ping. Small note, big impact. Now provisioned installations possible.

Installation Provisioning

During setup, the .inmanage/.env.example file is created, mirroring the standard .env file of Invoice Ninja. By pre-populating it with APP_URL and relevant DB_ data, and renaming it to .env.provision, it becomes a trigger for automated provisioning.Next time you run the script, it performs the following tasks in one batch:

  • Creates the database and database user
  • Downloads and installs the tar file
  • Publishes the .env.provision template to .env for production use
  • Generates the application key
  • Migrates the database
  • Creates an admin user
  • Reminds you to set up cron jobs
  • Prompts you to create an initial backup

Basically, you save a huge amount of time.

clean_install

  • Downloads and installs the latest version of Invoice Ninja from Github.
  • Target is the $INSTALLATION_DIRECTORY which must be set during installation in .env.inmanage
  • If the target folder already exists, it gets renamed and you start from scratch.
  • Creates a clean .env file
  • Generates the key into the .env file
  • Generates the cronjob string for you (must be installed manually)

Backup | Update | Install - Invoice Ninja - Shell Script

1 Like

@dros Thanks for sharing. So, how does your script work on an existing installation? Does it start everything from scratch? What about non-standard .env files or at least less common ones? Are the details copied over into the updated .env? I already have multiple cronjobs setup, does it still generate those?

Hey!

  1. Installation is the same; But you just do not install any new Invoice Ninja instance. You use the command-line switches for “backup” and “update” → See the documentation → GitHub - DrDBanner/inmanage: Easily install, update, and backup your self-hosted Invoice Ninja instance with a shell script.
    1.1. If you accidentially run the “clean_installation” or the “provisioned installation” process within an existing installation you get prompted, if you really really want to continue, since there’s already a folder. If you insist with YES here, the old folder gets renamed. So nothing gets deleted.
  2. The .env.provision file is a template generated from a standard .env, but it has 2 extra added fields for creating databases. Once it has been processed this .env.provision file becomes a normal .env file and gets moved over into a new installation. It’s its only purpose -create new installations. So, in an existing environment it’s just nothing you need to take care of. But if you use it as a kickstarter for a new installation everything you put in there gets copied over -except the DB_ELEVATED_* fields.
  3. This script does not backup any cronjobs nor does it register new ones. It just gives you the exact minimum cronjob line you need after an initial install.

Hope that clarifies your questions.

1 Like

Cheers! Yes, that helps.

1 Like

You have now footprints with this script → FAQ

1 Like

Brilliant. Thanks for that.