What you were given
The folder that arrives, what is inside it, what is deliberately missing, and how to make it yours.
What arrives is a folder named sourcecode. Inside it is the whole installation and nothing that is generated:
no node_modules, no .next, no .env.local, and no secrets of anybody's. That is what makes it small enough
to hand over and safe enough to put in version control the same day.
What is in it, and what is not
Three things are deliberately absent, and each one for a reason:
| Absent | Why |
|---|---|
node_modules | Downloaded, not shipped. Installing them is one command and they are different on every machine |
.env.local | It holds real keys. The folder ships .env.example, which holds the names and no values |
.next | The build output. It is regenerated by pnpm build and is machine-specific |
The quickstart guide, and this manual
Alongside the folder comes a quickstart guide as a PDF. It is the short form: one machine, one installation, running in ten minutes, with the order of the first four commands and where to put the first key.
This documentation is the long form, and it is the one served at /docs by the installation itself. The split is
deliberate rather than accidental:
| The quickstart PDF | This documentation | |
|---|---|---|
| Who it is for | Somebody installing it for the first time | Somebody running it, changing it or answering for it |
| Length | A handful of pages | Every screen, every variable, every failure |
| Covers the panel | No | Section by section |
| Covers the code | No | Folder by folder, with recipes |
| Gets updated | When the delivery is prepared | Whenever the folder is updated, because it lives in it |
Docs that ship with the thing they document
The manual is a folder of MDX files inside the installation, at
content/docs. There is no separate docs site to host and no external wiki to
keep in step: a change to a screen and a change to the page describing it are
the same commit.
If the PDF was not in your delivery
The quickstart is written separately from this manual and travels with the folder. If it is not there yet, nothing is missing from the installation: every step it covers is in Installing it and The first hour, in more detail than the quickstart has room for.
Making it yours
Put it in version control
If the folder did not arrive as a repository already, make it one. .gitignore is written for exactly this
shape: it ignores node_modules, .next, every .env file except .env.example, and the local state of the
installer.
git init
git add .
git commit -m "Loomis, as delivered"Nothing in it is a secret, and the first commit is the cleanest possible starting point for your own history.
Install and configure
pnpm install
pnpm configureTwo commands, and the second one is a conversation rather than a test. See Installing it.
Rename the things that are still generic
The product is called Loomis in the code, in the emails and in this manual. Changing it is a settings screen
rather than a search and replace: Brand → Branding sets the name, the marks and the colours. Two things are
worth knowing before you look:
- The name in the panel is what users see. The name in the code is what a developer reads, and leaving it alone is a legitimate choice.
- The wordmark files in
public/can be replaced from the panel, so an update does not put the shipped ones back.
Updating your copy
A copy of this folder is a starting point, not a subscription. When a newer release arrives, it is a newer folder, and the question is what to take from it.
| What you changed | How to take the update |
|---|---|
| Nothing yet | Replace the folder wholesale, then pnpm install and pnpm build |
| Content and settings only | Replace app/, components/ and lib/, and keep content/docs if you edited it |
| The code | Read the release notes, take the changes you need by hand |
| The documentation | Take content/docs if you want the newer manual, and keep your edits otherwise |
System → Setup & licensing in the panel exists for the case where the update should happen on the server
rather than on your laptop, and Updating it covers the commands either way.
A snapshot before an update, every time
Take one in System → Backups & exports and download it. It takes a minute,
and it is the difference between an update that went badly and an afternoon
spent reconstructing settings from memory.