# Upgrade Guide
Krayin upgrades follow Laravel's standard download new code, run migrations, republish assets shape — the goal of this page is to spell out the exact order so nothing gets reset and your local storage / custom views survive.
Before you start, make a full backup of:
- Your existing project directory.
- Your database (a
mysqldumpis enough). storage/app/public/— user-uploaded files live here.
If you skip a backup and the upgrade goes sideways, there's nothing to roll back to.
Working dir
The rest of this page assumes you've opened a command line at the project root of the new Krayin install — the directory that holds composer.json, artisan, and the packages/ folder. Adjust paths accordingly.
# ⬇️ 1. Get the latest Krayin
Pick one source:
- Official site — Download Krayin (opens new window).
- GitHub release — krayin/laravel-crm releases (opens new window).
Extract the archive into the directory you want the new install to live in.
# ⚙️ 2. Install dependencies
Inside the new project directory:
composer create-project
Composer pulls every PHP dependency that ships with the new Krayin release into vendor/.
# 🔑 3. Point the new install at your existing data
Open the .env file in the new project root and copy the database credentials from your old install:
DB_CONNECTION=mysql
DB_HOST=127.0.0.1
DB_PORT=3306
DB_DATABASE=krayin
DB_USERNAME=krayin
DB_PASSWORD=secret
Also copy across any custom values you set in the old .env — mail, queue, cache, app key. Don't regenerate APP_KEY if your old install set one; that key is used to decrypt existing sessions and cookies.
# 🧱 4. Cache the new config
php artisan optimize
Or, if you only want the config cache and skip route/view caching:
php artisan config:cache
# 🗄️ 5. Run pending migrations
php artisan migrate
This applies every migration that's new in the upgrade target. Your existing data stays in place — only schema changes run.
Never run `db:seed` on an upgrade
The seeders set up default roles, pipelines, and configuration values. Running them on top of an existing install can overwrite custom settings. If a release introduces seed data you actually need, the release notes will call out exactly which seeder to run with --class=....
# 🔗 6. Re-link the storage directory
php artisan storage:link
This recreates public/storage as a symlink to storage/app/public, the way Laravel expects.
# 📁 7. Restore uploaded files
Copy the contents of the old install's storage/app/public/ over the new install's same directory:
cp -R /path/to/old-krayin/storage/app/public/. /path/to/new-krayin/storage/app/public/
Local-storage paths
If your existing install also reads from a different storage/ path (custom uploads, logs you want to preserve), copy those across too. Anything left only in the old project's storage/ is lost when you cut over.
# 📦 8. Publish vendor assets
php artisan vendor:publish --all
This copies new translation strings, config defaults, and view stubs into your resources/ and config/ directories.
Don't pass `--force`
--force overwrites every published file — including any view you've customised. Only use it if you're knowingly wiping your customisations.
# ✅ 9. Done
Browse the admin and confirm everything renders. If something looks off, the most common culprits are:
- Stale config — run
php artisan optimize:clearto flush every cache and try again. - Missing migration —
php artisan migrate:statusshows whether anything is pending. - View overrides under
resources/views/vendor/that don't match the new package version — re-publish just that package's views and re-apply your changes.
# 📋 Dependency reference
The composer + npm package lists move forward with each release. The table below shows the kind of change to look out for when reading the release notes — specific version numbers shift with every release, so always cross-check against the new composer.json.
# Composer dependencies — typical changes
| Type of change | Example | What to do |
|---|---|---|
| Added | mpdf/mpdf introduced for PDF generation. | Run composer install; new packages are pulled automatically. |
| Removed | krayin/rest-api is no longer bundled — it's a separate package now. | If you used the bundled version, install it explicitly with composer require krayin/rest-api. |
| Upgraded | laravel/ui ^4.0 → ^4.5. | composer update; check the upgraded package's own changelog for breaking changes. |
| No change | laravel/framework, prettus/l5-repository, etc. | Nothing to do. |
# Autoload paths
New packages that ship inside core Krayin add new entries to the root composer.json autoload.psr-4 map:
"Webkul\\Warehouse\\": "packages/Webkul/Warehouse/src",
"Webkul\\Automation\\": "packages/Webkul/Automation/src",
"Webkul\\DataGrid\\": "packages/Webkul/DataGrid/src"
When you upgrade, your composer.json should match the upstream one. If you copied the file from the old project, diff it against the new project's composer.json and merge any new autoload entries by hand. Then:
composer dump-autoload
# Dev dependencies
Notable dev-tool additions over recent versions:
laravel/pint— the formatter Krayin now uses. Runvendor/bin/pintbefore sending a PR (see Contribution Guide).pestphp/pest+pestphp/pest-plugin-laravel— test runner used by the agent-skillspest-testingskill.
# 🧪 Verify
After the upgrade:
php artisan migrate:status # all migrations should show "Ran"
php artisan optimize:clear # flush every cache
php artisan route:list # quick sanity check that routes still resolve
Then exercise the parts of the admin you customise — create a lead, send an email, run a DataGrid filter. If a published view looks broken, re-publish just that package's views and re-apply your changes against the new template:
php artisan vendor:publish --provider="Webkul\Admin\Providers\AdminServiceProvider" --tag=views --force
# 📝 Next steps
- Contribution Guide — if the upgrade surfaced a bug or missing feature, this is the workflow for sending a fix upstream.
- Best Security Practices — revisit after every major upgrade; new releases sometimes change recommended headers or hardening defaults.