Download the PHP package posio/cabinet-kit without Composer

posio/cabinet-kit

Quick install

The package is not on Packagist — it is installed straight from its git repository, so any machine with network access to GitHub can install it; no local checkout of the package is needed.

Run inside an existing Laravel 11/12 + Inertia + Vue 3 project:

Then open /cabinet/register and create the first user — registration also creates the account (the "Company name" field), so no separate account-creation step is needed on a fresh install.

Signing in as one of the seeded accounts (sa / admin, see system_users in config/cabinet-kit.php) instead opens the password screen and stops there: their installed password is written in that config and is the same in every project using this package, so the cabinet opens only after it has been replaced. Set 'force_system_password_change' => false if those passwords are managed outside the application.

Notes on the git source

• Composer needs git on PATH; if it is missing, Composer falls back to downloading zip archives from GitHub, which also works.
• To follow the unreleased tip instead of a tagged release, require dev-main and set "minimum-stability": "dev" + "prefer-stable": true in the host composer.json.
• Private-repo / rate-limit case: authenticate Composer once with a GitHub token — composer config --global github-oauth.github.com <token>.
• Write the constraint as ^0.3, not 0.3: a two-segment version is an exact version to composer (it normalizes to 0.3.0), so 0.3 installs the very first release of the line and hides every later tag — composer update then reports the project as current forever. cabinet-kit:install and cabinet-kit:sync-config rewrite such a constraint to its range form, and cabinet-kit:doctor fails on it.
• To pin an exact release, use a full tag instead of a range, e.g. composer require posio/cabinet-kit:0.3.31 (left alone by the commands above — a three-segment pin is read as deliberate).
• Offline machines: clone or copy the repo to that machine and point the repository at the local path — composer config repositories.cabinet-kit vcs /path/to/posio-cabinet-kit (a plain filesystem path works as a vcs source because the copy is a git repo).

Updating

The install command drops two launchers in the project root — updcab.bat for Windows and updcab for a Linux/macOS host over ssh. Either one performs the whole Update procedure in order and stops at the first failing step:

Requirements and what those commands actually do — below; the full step-by-step is in Update.

Base admin-panel scaffolding extracted from posio.cabinet: multi-tenant accounts, per-account roles/permissions (Spatie Permission teams), bundled auth (login, register, logout, password reset, email verification), a Settings shell, a log viewer, a collapsible side-menu layout, and a small Vue 3 UI kit — for bootstrapping a new Laravel + Inertia + Vue 3 project's admin part.

Not a finished product — a shell you extend per project. See docs/ARCHITECTURE.md and docs/EXTENDING.md.

Requirements

• Laravel 11/12, PHP 8.2+
• Inertia.js (Laravel adapter) + Vue 3, Options API
• spatie/laravel-permission, opcodesio/log-viewer (pulled in automatically)
• tightenco/ziggy (composer) + npm: vue, @inertiajs/vue3, ziggy-js, @iconify/vue, @headlessui/vue, @vuepic/vue-datepicker, vue-final-modal, vee-validate, vue-i18n, dayjs, axios, sweetalert2, vue3-toastify, date-fns, @fontsource/inter, @fontsource/roboto, @fontsource/open-sans, @fontsource/inter-tight, @fontsource/pt-sans — package pages resolve URLs through route() and use Iconify icons/date inputs with bundled fonts, confirmation dialogs and toasts. php artisan cabinet-kit:install adds them to package.json for you; cabinet-kit:doctor re-checks the list.
• A User model with password/email_verified_at columns (Laravel's default users migration already has both)
• php artisan storage:link — the brand images an operator uploads in the site/cabinet settings sections are served from storage/app/public/site/
• Optional: spatie/laravel-sitemap, needed only by sitemap:generate of the SEO section

Install (in a consumer project)

Commands — see Quick install above.

The install command publishes config/cabinet-kit.php and config/cabinet-kit-redirects.php, enables Spatie Permission teams before migrations, resolves auth-route conflicts, scaffolds the cabinet Vite entry (resources/_admin/js/cabinet.ts by default), patches vite.config, tailwind.config and app/Models/User.php with .bak backups, drops updcab.bat and updcab (the one-step update launchers) in the project root, runs migrations, seeds base roles, and finishes with cabinet-kit:doctor.

If the database already contains users, the command asks whether to delete them (with their accounts, memberships and role assignments) before seeding. The default answer is no — say yes only on a database you are willing to reset. --purge-users answers that prompt up front; with --no-interaction and no flag nothing is deleted.

Every CabinetKit page renders into the package's own Blade root view (cabinet-kit::app) with its own Vite entry — the host's main app view and entry are untouched.

Visit /cabinet/register afterwards to create your first user + account — registration bundles account creation (a "Company name" field), so there's no separate account-creation step for a brand-new install.

Update

Run the launcher from the project root — updcab.bat on Windows, ./updcab on a Linux/macOS host (that one is the whole update on a production server over ssh). Both are scaffolded by the install command, run exactly the six steps below and stop at the first one that fails. Everything after this paragraph describes what they do (and what to run by hand elsewhere).

./updcab differs from the batch file only where a server differs from a workstation:

• migrate --force — a production run has no tty to answer the confirmation prompt with;
• when APP_ENV=production, php artisan optimize runs after the caches are cleared, so the site does not stay uncached (see the note after step 6);
• ./updcab --no-build skips npm install && npm run build for a deploy whose assets are built elsewhere; without the flag a missing npm stops the update instead of silently leaving stale assets;
• the PHP is checked before anything runs. Shared hosting serves the site on the version its panel selected while the shell of the same account still starts an old default, and on that one step 1 fails with a wall of your php version (7.4.33) does not satisfy that requirement. When php is older than 8.2, the launcher picks another binary — from the usual names and per-version paths (php8.3, /opt/php83/bin/php, /opt/alt/php83/usr/bin/php, /opt/cpanel/ea-php83/root/usr/bin/php) — and says which one it took. Preference goes to the version the site is actually served with, read from the handler line of .htaccess; without one it takes the oldest supported, since what Composer resolves for 8.2 also runs on a newer binary while the reverse installs code the site cannot execute. Composer runs under the same interpreter — a phar and a shebang script both otherwise fall back to the default php. PHP_BIN=/usr/bin/php8.3 ./updcab overrides the choice.

When composer is not in PATH — the usual case on shared hosting — the launcher looks for composer2, then for a phar or binary in the project root, in ~, in ~/bin and in the common system locations, and finally asks the login shell to resolve it (a host that adds Composer to PATH in ~/.bashrc, or declares it there as an alias over a phar, gives it to an interactive session only — which is why it runs by hand while the update does not find it). If the host keeps it somewhere else, name it: COMPOSER_BIN=/opt/php83/bin/composer ./updcab. If the host has no Composer at all, install it once into the project root and the launcher picks it up from there:

If the server answers Permission denied, the executable bit did not survive the trip (a file committed from Windows carries none): chmod +x updcab there, or git update-index --chmod=+x updcab in the repository so it arrives set on the next deploy. sh updcab works regardless.

Full procedure, in order:

On production, re-cache after step 4 as usual (php artisan config:cache route:cache view:cache) — the caches must be rebuilt because package routes and views changed, not because the update needs anything special.

cabinet-kit:install registers sync-config in your composer.json post-update-cmd, so from then on composer update runs it for you (step 2 is then redundant): it keeps the npm dependency list and the Tailwind content glob for the package templates current, creates config files a new package version introduced, and only reports new config/cabinet-kit.php keys (that file is never rewritten). Rebuild assets afterwards if it patched anything.

Read its output: keys it lists are new settings your config/cabinet-kit.php does not have yet — copy them in by hand, otherwise the package falls back to its own defaults for them. cabinet-kit:doctor at the end reports anything still unwired.

Vue/SCSS/routes/migrations are read straight from vendor/posio/cabinet-kit/ — nothing was copied into your project, so there's nothing to merge. Anything you deliberately overrode in resources/_admin/overrides/ keeps working untouched.

Which version you get

composer update posio/cabinet-kit only moves inside the range in your composer.json (^0.3 stays on 0.3.*). A bare 0.3 there is not that range — composer reads it as the single release 0.3.0 and silently stops offering updates; cabinet-kit:doctor reports it, and cabinet-kit:sync-config rewrites it to ^0.3 (run composer update posio/cabinet-kit once more afterwards). Breaking changes — renamed config keys, removed props on released Vue components, changed route names — arrive as a major bump, so crossing one is a deliberate edit of the constraint followed by composer update, plus a read of docs/CHANGELOG.md.

To see what is available before updating:

If a dev-main install stops picking up new commits, Composer is serving a cached clone — composer clearcache, then update again.

Customizing

• Menu items, assignable roles, log-viewer path → config/cabinet-kit.php (survives updates for free).
• Where sign-in, registration, email confirmation and sign-out land → config/cabinet-kit-redirects.php. Point home/after_login at your own route to open the cabinet on your own page.
• Styles → resources/_admin/scss/cabinet-kit-overrides.scss (scaffolded by install, loaded after the kit so your rules win; redefine --ck-* tokens or re-declare element classes — never edit the package's own scss).
• Deeper changes → resources/_admin/overrides/pages/... (checked before the package's own version — see docs/EXTENDING.md).
• Brand (site name, favicon, logos, default theme) → the Site settings and Cabinet settings sections of the cabinet itself. To make the host's own public pages follow them, and to drive their meta from the SEO section, follow docs/cabinet-kit/ — installed into the project and refreshed on every update (source: docs/host/ here).

Uninstall (remove from a project)

There is no uninstall command — cabinet-kit:install patches the host's own files, and undoing that automatically would mean rewriting files you have edited since. The steps below are the exact reverse of what install did.

Back up the database first: step 1 drops tables and columns.

1. Roll back the package migrations (while the package is still installed — its migration files must be readable):

That removes the accounts, user_has_accounts and admin_links tables, the settings/social-id columns added to users, and the is_system columns on roles/permissions. Migrations recorded from other paths are skipped with a "migration not found" note — that is expected, not an error.

Spatie's own permission tables were published into database/migrations/, so they are the host's files now: keep them if the project still uses roles, otherwise roll them back and delete them too. Seeded rows (roles, admin links, system users) disappear with their tables.

2. Remove the composer package:

spatie/laravel-permission, opcodesio/log-viewer and inertiajs/inertia-laravel came in as its dependencies and go with it. If the project keeps using any of them, composer require it explicitly first.

3. Undo the host-file patches. Each patched file has a .bak copy from install time — useful as a reference, but do not blindly restore it: it predates every change you made since. Edit by hand:

4. Delete the files install created:

5. Rebuild and clear:

Nothing else of the package remains in the project: Vue/SCSS/routes/views were always read from vendor/, which step 2 deleted. If the host relied on the bundled auth routes (login, register, password.*, verification.*), those names are now gone — restore the project's own auth routes before deploying.

Developing this package itself

Open this repo directly (F:\Packages\posio-cabinet-kit) and follow its own CLAUDE.md. Tag a new semver version after merging a change; consumer projects pick it up with composer update posio/cabinet-kit.