Updating
Pull the latest Inertia Start release into your existing application.
Inertia Start is a starter kit, not a dependency: once your project is created, the code is yours, and you are free to modify any part of it. Updates are therefore not installed by a package manager, they are merged into your own Git history.
You need a shared Git history
This guide assumes you cloned the repository. If you started from a downloaded release ZIP, your project shares no history with Inertia Start and Git has nothing to merge. In that case, clone the repository and copy your customizations over, or compare the two versions manually.
Updating requires an active license: the repository is served behind your API key and access is checked on every fetch. If your license expires, the code you already have keeps working, but you can no longer fetch new releases until you renew it.
Update Steps
Add the Inertia Start Remote
If you followed the installation guide, the Inertia Start repository is already configured as the core remote and you can skip this step. Otherwise, add it now:
# We name the remote `core` in this example, but you can name it as you like
git remote add core https://[email protected]/git/inertia-start.gitRotating your API key
The key is stored in plaintext in .git/config. If you revoke it or create a new one, point the remote to the new key:
git remote set-url core https://[email protected]/git/inertia-start.gitFetch the Latest Code
Fetch the branches and the release tags:
git fetch core --tagsNothing in your project changes yet: fetching only downloads the new commits.
Choose a Version
List the versions you just fetched:
git tag -l 'v*'Each variant has its own tags. Teams releases carry a -teams suffix:
| Variant | Branch | Tags |
|---|---|---|
| Standard | main | v1.0.0 |
| Teams | teams | v1.0.0-teams |
The changelog of every release is also available on the Inertia Start product page of your account. Read it before updating: it lists the breaking changes and the manual steps a release may require.
Merge the Update
Check out the branch your project lives on, then merge the version you picked:
git checkout main # or whichever branch your project lives on
# Update to a specific version (for example 1.0.0):
git merge --no-ff refs/tags/v1.0.0
# Or retrieve all changes to date:
git merge --no-ff core/mainTeams projects need the `-teams` tags
The teams branch is built on top of main, which means plain vX.Y.Z tags are already part of its history. Merging v1.0.0 into a Teams project silently does nothing: always merge v1.0.0-teams.
Merging like this:
- retains the original commits and timestamps from both the remote and your own branch
- keeps your branch history intact
- creates a merge commit even when a fast-forward would be possible (thanks to
--no-ff), which makes it easy to see later when each update was merged
Resolve Conflicts
Git will report a conflict for every file you customized that also changed upstream. Resolve them, then commit the merge:
git status
# edit the conflicting files
git add .
git commitConflicts are much easier to handle when your own code lives in its own files. Adding new components, routes or config entries rarely conflicts, whereas rewriting the files shipped by the starter kit does.
Apply the Update
A new version usually brings new dependencies, migrations and assets. Install and rebuild everything:
composer install
npm install
php artisan migrate
npm run buildIn development, composer run dev rebuilds the assets for you, so npm run build is only needed for production.
Finally, run your test suite and go through the changelog once more for the manual steps the release may require.
Staying Up to Date
Merging often is easier than merging rarely: each update is smaller, and so is the set of conflicts. Updating one release at a time, rather than jumping several versions at once, keeps the changelog relevant and the conflicts readable.