Fundamentals

Where modules live

Modules/Services/    provisionable products   category: "service"
Modules/Gateways/    payment processors       category: "gateway"
Modules/Providers/   OAuth logins             category: "social"
Modules/Addons/      everything else          category: "addons"

The directory and the category in module.json have to agree. If they don’t, an imported module lands in the wrong place.

Your namespace has no group segment. A module at Modules/Services/AcmePanel is namespaced Modules\AcmePanel, not Modules\Services\AcmePanel.

module.json

{
    "name": "AcmePanelService",
    "alias": "acmepanelservice",
    "description": "Provision and manage Acme game servers.",
    "category": "service",
    "display": "Acme Panel",
    "providers": ["Modules\\AcmePanelService\\Providers\\AcmePanelServiceServiceProvider"],
    "hasSettings": true,
    "settingsUrl": "/admin/acme-panel/settings",
    "permissions": { "...": "see below" },
    "logo": "/modules-logos/acme-panel-service.png"
}

string

required

StudlyCase. This is your namespace segment and what gets stored in Service.module.

string

required

Lowercased name. Used for config, translation and view keys.

string

required

Shown in the admin module list, and at checkout for gateways.

string

required

One of service, gateway, social, addons. Decides the group directory.

string[]

required

Fully qualified provider class names.

string

Friendly name for the UI. Always set it: without it the UI falls back through a chain that can end up showing your alias.

object

Admin permission declarations. See Admin permissions.

mixed

OAuth providers only. See the OAuth guide.

The service provider

Pick the base for your group and you’re done.

Service
Gateway
OAuth provider
Addon

use App\Modules\ServiceModuleServiceProvider;

class AcmePanelServiceServiceProvider extends ServiceModuleServiceProvider
{
    protected string $name = 'AcmePanelService';
    protected string $nameLower = 'acmepanelservice';
}

use App\Services\Payment\Modules\GatewayModuleServiceProvider;

class AcmeGatewayServiceProvider extends GatewayModuleServiceProvider
{
    protected string $name = 'AcmeGateway';
    protected string $nameLower = 'acmegateway';
}

use App\Modules\OAuthProviderServiceProvider;

class AcmeProviderServiceProvider extends OAuthProviderServiceProvider
{
    protected ?string $socialiteDriver = 'acme';
    protected ?string $socialiteProvider = \SocialiteProviders\Acme\Provider::class;
}

use App\Modules\AddonModuleServiceProvider;

class LoyaltyRewardsServiceProvider extends AddonModuleServiceProvider
{
}

Both $name and $nameLower are optional. They’re derived from the namespace, so an empty class body works.

What the base does for you

Translations

From lang/, or from resources/lang/modules/{alias}/ if published.

Config

Merges config/config.php under the {alias} key, and publishes it to config/{alias}.php.

Views

Registers Blade views and a component namespace.

Migrations

Loads them from database/migrations.

Sub-providers

Registers your EventServiceProvider and RouteServiceProvider, skipping either if it doesn’t exist, so you don’t have to ship empty ones.

Schedules

Loads routes/console.php after the app has booted, which is when the scheduler is available.

Hooks you can override

Hook	Use it for
`moduleCommands(): array`	Artisan commands to register
`moduleSchedule(Schedule $schedule): void`	Cron jobs you don’t declare in `routes/console.php`
`bootModule(): void`	Boot-time wiring: middleware aliases, listeners, Inertia shares
`registerModule(): void`	Container bindings

protected function moduleCommands(): array
{
    return [SyncAcmeStock::class];
}

protected function moduleSchedule(Schedule $schedule): void
{
    $schedule->command('acme:sync-stock')->everyFiveMinutes()->withoutOverlapping();
}

Don’t schedule by overriding registerCommandSchedules(). Four modules used to do that, which meant their routes/console.php never loaded and their cron jobs were easy to lose in a refactor.Use moduleSchedule() or routes/console.php, not both, or the job runs twice.

The commands hook is moduleCommands(), not commands(), because ServiceProvider::commands() already exists with a different signature.

Four addons (Affiliates, Blog, KnowledgeBase, News) still use an older hand-written provider. Don’t copy those.

RouteServiceProvider

use App\Modules\BaseModuleRouteServiceProvider;

class RouteServiceProvider extends BaseModuleRouteServiceProvider
{
    protected string $name = 'AcmePanelService';

    protected array $middlewareAliases = [
        'acme.feature' => CheckFeatureEnabled::class,
    ];
}

The base maps routes/api.php under the api group with an api. name prefix, and each file in $webRouteFiles (default ['web.php']) under web. Missing files are skipped. Set $hasApiRoutes = false if you ship no API routes.

Route files

File	Loaded how	For
`web.php`	Mapped directly	Public and user routes, plus `require`s of the rest
`api.php`	Mapped directly, prefixed `api`, named `api.`	Webhooks, stateless endpoints
`settings.php`	`require` from `web.php`	Admin pages under `/admin/...`
`panel.php`	`require` from `web.php`	Customer pages under `/service/{serviceId}/...`
`payment.php`	`require` from `web.php`	Gateway create, success, cancel
`console.php`	The provider, after boot	`Schedule::command(...)`

Only web.php and api.php get mapped. The rest come in like this:

routes/web.php

require __DIR__.'/settings.php';
require __DIR__.'/panel.php';

Admin permissions

Declare them in module.json and core merges them into both places that matter: the map PermissionMiddleware uses, and the catalogue that draws the admin role editor.

module.json

"permissions": {
    "category": "gateway_settings",
    "category_name": "Gateway & Service Settings",
    "nodes": {
        "/admin/acme-panel/settings": {
            "label": "Manage Acme Panel",
            "routes": ["/acme-panel/settings", "/acme-panel/test-connection"]
        }
    }
}

Node keys get stored in the database (AdminRole.permissions JSON). Renaming one after release silently takes access away from every role that had it.

Routes leave off the /admin prefix

module:doctor tells you if you forget.

Every node needs a category

Without one, getCategoryForPermission() returns null, the role editor draws no checkbox, and the * wildcard won’t match. Only a superadmin could ever use it.

Nodes can be method-specific

Prefix with an HTTP verb: "DELETE:/admin/acme-panel/backups/{id}".

Core always wins

You can’t redefine or shadow a core route’s permission.

A node with no routes is fine

Use it for something your controller checks itself with $user->hasPermission(...).

For one-off routes you can skip the manifest and name it inline:

Route::get('/admin/acme-panel/settings', [SettingsController::class, 'index'])
    ->defaults('permission', '/admin/acme-panel/settings');

Existing categories you can add to: gateway_settings (“Gateway & Service Settings”) and addon_module_settings (“Addon Module Settings”).

Every bundled module declares permissions this way, so copy whichever is closest. Modules/Gateways/StripeGateway is the simplest. Modules/Services/PterodactylService has several nodes including a method-specific one.

Admin settings with no frontend work

Extend ModuleSettingsController, describe your fields, and core builds the page. No React needed. It renders the shared admin/ModuleSettings page and pulls your display name, logo and module type straight from module.json, so the header and back link match your module.

class SettingsController extends ModuleSettingsController
{
    protected function settings(): array
    {
        $c = AcmeCredential::first();

        return ['url' => $c?->url ?? '', 'api_key' => $c?->api_key ?? ''];
    }

    protected function settingsDefinition(array $settings): array
    {
        return [
            'title' => 'Acme Panel',
            'description' => 'Where to reach your Acme install.',
            'update_url' => url('/admin/acme-panel/settings'),
            'test_url' => url('/admin/acme-panel/test-connection'),
            'fields' => [
                ['name' => 'url', 'type' => 'url', 'label' => 'API URL', 'required' => true],
                [
                    'name' => 'api_key',
                    'type' => 'password',
                    'label' => 'API Key',
                    'required' => true,
                    'configured' => $settings['api_key'] !== '',
                ],
            ],
        ];
    }
}

Field types

Type	Notes
`text`, `email`, `url`	Plain inputs
`password`	Reveal toggle, and shows “Stored” when `configured` is true
`number`	Takes `min`, `max`, `step`
`textarea`	Takes `rows`, renders monospace, full width
`select`	Takes `options` as `[['value' => ..., 'label' => ...]]`
`toggle`	Boolean switch
`readonly`	Display only, with a copy button. Good for generated IDs and callback URLs

Every field also takes placeholder, help, max_length, full_width, copyable, and visible_when for conditional display.

Tabs

Declare groups and tag fields with group to split a long form into tabs. Tabs only appear when more than one group has visible fields, so a small module stays a single page.

'groups' => [
    ['key' => 'connection', 'label' => 'Connection', 'description' => 'How to reach the panel.'],
    ['key' => 'billing', 'label' => 'Billing'],
],
'fields' => [
    ['name' => 'url', 'type' => 'url', 'label' => 'API URL', 'group' => 'connection'],
    ['name' => 'markup', 'type' => 'number', 'label' => 'Markup %', 'group' => 'billing', 'min' => 0],
],

Saving submits every tab, not just the visible one.

Test connection

Set test_url and the header gets a Test connection button that POSTs there. Return a back()->with('success'|'error', ...) and it surfaces as a toast.

'test_url' => url('/admin/acme-panel/test-connection'),
'test_label' => 'Check API access',   // optional

Use url() here, not route(). route() throws when the module is disabled, which makes the definition impossible to build in a test.

Status cards

Sidebar panels for read-only facts. status_tone accepts success, warning, danger or neutral, and rows can be copyable.

'status_cards' => [[
    'title' => 'Connection',
    'status' => $settings['api_key'] ? 'Configured' : 'Not configured',
    'status_tone' => $settings['api_key'] ? 'success' : 'neutral',
    'rows' => [
        ['label' => 'Webhook URL', 'value' => url('/api/acme/webhook'), 'copyable' => true],
    ],
]],

Notices containing a URL get a Copy URL button automatically.

Two helpers you get for free

resolveSecret()

resolveSecret($request, 'api_key', $stored) keeps the saved secret when the form posts an empty password box.

flushPaymentGatewayCache()

Gateways must call this after saving or checkout keeps a stale list for five minutes.

Always ship a Test Connection action. It’s the difference between a five-minute setup and a support ticket.

Credentials

class AcmeCredential extends Model
{
    protected $table = 'acme_credentials';
    protected $fillable = ['url', 'api_key'];
    protected $casts = ['api_key' => 'encrypted'];
}

The column must be TEXT, not string, because ciphertext is much longer than what went in.

Only put encrypted on a brand new column. The cast uses Crypt::encrypt(), which serialises. The older credential models hand-roll Crypt::encryptString(), which doesn’t. Mixing them breaks decryption:

encryptString then decryptString : fine
encryptString then decrypt       : throws

Convert an existing model only with a migration that re-encrypts the column first.

Migrations

Normal Laravel migrations in database/migrations/. Prefix your tables with the module name, since every module shares one database. Touching a core table is allowed. Make the column nullable and the migration idempotent, because modules get enabled and disabled over and over:

if (! Schema::hasColumn('users', 'acme_id')) {
    Schema::table('users', fn (Blueprint $t) => $t->string('acme_id')->nullable());
}

Never change or drop a core column. Add your own, or use a side table with a foreign key so your module stays removable.

Events

Core fires 26 events from app/Events/. The useful ones: InvoicePaid, ServicePaymentCompleted, ServiceRenewed, ServiceSuspended, ServiceTerminated, ServiceCancelled, ServiceUpgradeCompleted, AddonPurchased, UserRegistered, TicketCreated.

protected $listen = [
    \App\Events\ServicePaymentCompleted::class => [SendAcmeWelcome::class],
];

Two mistakes that have both happened here:

Keep configureEmailVerification() as a no-op

Laravel’s base EventServiceProvider registers SendEmailVerificationNotification from every provider that doesn’t override it, and each copy is another email to the same person. Five gateways were missing this and new users got six verification emails each.

protected function configureEmailVerification(): void {}

Extending EmptyGatewayEventServiceProvider gives you the override already.

Never list a core listener in your $listen

Anything in app/Listeners is already picked up by event discovery, so listing it again registers it twice. Pterodactyl and Pelican both did this with App\Listeners\LogUserRegistration, and every signup was written to the audit log three times.

Add implements ShouldQueue to your listeners unless they genuinely have to be synchronous. A listener that throws inline can break checkout for everyone.

All of these are post-events. There’s currently no way to veto or change an action before it happens.

Frontend pages

Module pages aren’t Vite entries. Each module has a register.ts that maps Inertia page names to dynamic imports.

import { registerModulePages } from '../../../../../resources/js/modulePages';

registerModulePages({
    'AcmePanel/Console': () => import('./Pages/Console.tsx'),
});

return Inertia::render('AcmePanel/Console', ['data' => $data]);

Namespace every key with your module name so it can’t collide, and count the ../ carefully. It’s five levels up.

This is deliberate. Listing 100+ module .tsx files as Vite entries duplicates chart.js, monaco and xterm across parallel chunk graphs and blows up the build.

Your pages are bundled into the app’s own build, which has two consequences:

Pages ship when the frontend is rebuilt

Vite finds every Modules/*/*/resources/js/register.ts at build time. A new page, or a change to an existing one, reaches the site after npm run build. Octane doesn’t need a reload for this, because the workers pick up the new build manifest on their own.

Only core's packages are available

A module’s own package.json is never installed. Your pages can import anything in the root package.json (React, Inertia, lucide-react, framer-motion, chart.js, Monaco, xterm and the rest) and core’s components, hooks and contexts through the @/ alias. Don’t add a package to the root package.json for your module either, because every update replaces it.Composer is the same: updates run composer install against core’s lock file, so a package your module’s composer.json requires won’t be installed on customer servers.

Enabling a module

Whether a module is on or off is stored in the module_statuses database table.

modules_statuses.json is only read once, to fill an empty table on a fresh install. Editing it by hand does nothing. Use the admin panel or module:enable and module:disable.

Admin panel
Command line

Go to Admin, Modules and flip the switch. Enabling runs the module’s migrations, clears the permission and checkout-gateway caches, and reloads the Octane workers once the response has gone out. There’s nothing else to run.

php artisan module:enable AcmePanelService
php artisan module:migrate AcmePanelService
php artisan octane:reload

The reload isn’t optional. Each worker read the module list when it booted, so until the workers reload, the site behaves as if the module were still off. Disabling works the same way.

make:module leaves a new module disabled and regenerates Composer’s autoloader for you.

The autoloader trap

Getting this wrong takes the whole site down, so it’s worth understanding.A worker loads the module list and Composer’s autoloader together when it boots. If an enabled module’s provider class isn’t in the autoloader at that moment, nwidart tries to instantiate a class that doesn’t exist and the worker fails to boot. Every worker does the same, so every request fails, artisan included, and you can’t disable the module from the admin panel either.

Under Octane the trap springs at the next reload: the one an admin toggle triggers, a manual octane:reload, a deploy or a reboot. One rule avoids it. Dump the autoloader before you enable the module, never after:

composer dump-autoload
php artisan module:enable AcmePanelService
php artisan module:migrate AcmePanelService
php artisan octane:reload

make:module --enable does the dump and checks that the provider loads before it flips the switch. You still have to reload Octane yourself.

On a server that runs PHP-FPM instead of Octane, the order is: dump the autoloader, reload PHP-FPM, then enable. See Servers still on PHP-FPM.

If you have already broken it

composer dump-autoload
sudo systemctl restart dezerx-octane

If the module’s classes really are gone, artisan can’t boot to disable it. Switch it off in the database instead, then restart Octane again:

UPDATE module_statuses SET enabled = 0 WHERE name = 'AcmePanelService';

If you deleted the module’s folder, delete its row as well.

Installing a module

For a module you didn’t generate on this server, from the marketplace or from a colleague. There’s no upload button in the admin panel: modules are installed on the server itself.

Put it in the folder that matches its category

`category` in `module.json`	Folder
`service`	`Modules/Services/{name}`
`gateway`	`Modules/Gateways/{name}`
`social`	`Modules/Providers/{name}`
`addons`	`Modules/Addons/{name}`

The folder name must be the module’s name, exactly. Make sure the user the site runs as owns it:

sudo chown -R www-data:www-data Modules/Addons/LoyaltyRewards

Regenerate the autoloader

composer dump-autoload

Rebuild the frontend, if it has pages

Only needed when the module ships a resources/js/register.ts.

npm run build

Reload Octane

php artisan octane:reload

Workers scan Modules/ only when they boot, so the module won’t appear in Admin, Modules until they reload.

Enable it

From Admin, Modules, which also runs its migrations.

Updates keep your modules

An update replaces the application directory, then puts back every module that doesn’t ship with the new release. It rebuilds the autoloader and the frontend afterwards, and enabled state lives in the database, so there’s nothing for you to run. Two rules decide where a module ends up:

Bundled names win

If a module with the same name ships in the new release, the release’s copy is kept and yours is dropped. Don’t patch a bundled module in place: copy it under a new name.

The name suffix picks the folder

The updater sorts custom modules by name: ...Service into Services, ...Gateway into Gateways, ...Provider into Providers, and everything else into Addons. An addon called UptimeService would be moved into Modules/Services/ on the next update.make:module adds the right suffix for you. Keep it when you rename.

Running under Octane

DezerX serves HTTP through Laravel Octane on RoadRunner, with NGINX in front. Each worker boots the application once and then handles thousands of requests with it. That’s where most of the speed comes from, and it changes two things for module authors: when your changes go live, and what your code may keep between requests.

Making changes live

You changed	Run
PHP in a module: controllers, services, providers, routes, `config/`	`php artisan octane:reload`
Code that runs in a queued job: provisioning, renewals, queued listeners	`php artisan queue:restart` as well
Added a class Composer doesn’t know about yet	`composer dump-autoload`, then reload
Enabled or disabled a module from the command line	`php artisan octane:reload`
A page or component in `resources/js`	`npm run build`, no reload needed
Enabled or disabled a module in the admin panel	Nothing. It reloads for you

Two ways to reload from a shell:

sudo -u www-data php artisan octane:reload

sudo systemctl reload dezerx-octane

Or use Admin, System: Reload Octane reloads the workers, and Restart All also restarts the queue workers. Reloads are graceful, so requests in flight finish on the old workers first.

Run artisan as the user the site runs as, usually www-data. From another account octane:reload can report “Octane server is not running” when it is, and files that root creates under storage/ can’t be written by the site afterwards.

In development

composer dev:octane starts Octane with --watch, which reloads by itself when PHP under Modules/*/*/app or Modules/*/*/routes changes. Older modules keep Services/ and Http/ at the module root, outside what it watches, so reload by hand after editing those.

Servers still on PHP-FPM

When a server lacks the PHP extensions RoadRunner needs, the installer falls back to PHP-FPM. There, reload PHP-FPM instead of Octane. Its OPcache doesn’t re-check files, so changed PHP isn’t picked up until you do:

sudo systemctl reload php8.4-fpm

Use your PHP version in the service name. systemctl status dezerx-octane tells you which setup you have.

Code that’s safe in a long-lived worker

Never exit() or die()

exit(), die() and $response->send() stop the worker, not just the request. To end a request early, throw the response instead:

throw new HttpResponseException(redirect('/login'));

Boot code runs once per worker

boot(), bootModule(), registerModule() and the top level of your route files run when a worker starts, not on every request. Registering routes, listeners, middleware and bindings there is right. Reading the current user, the request, the session or a setting there is wrong: you get whatever the first request had, for the life of the worker.Per-request work belongs in middleware. Register it once from your provider, the way Affiliates captures referral codes:

use Illuminate\Contracts\Http\Kernel;

protected function bootModule(): void
{
    $this->app->make(Kernel::class)->appendMiddlewareToGroup('web', CaptureReferralFromQuery::class);
}

No request state in statics or singletons

A static property or a singleton() binding lives as long as the worker. Put the current user, a customer’s service or anything from the request in one, and the next customer gets it. Bind services that hold per-request state with scoped(), which Octane throws away after every request:

protected function registerModule(): void
{
    $this->app->scoped(AcmeCart::class);
}

Memoize shared data with RuntimeSnapshot

A static cache of database rows goes stale for the life of the worker. For data that rarely changes and is the same for everyone, like plans, settings or a price list, use RuntimeSnapshot:

use App\Support\RuntimeSnapshot;

$plans = RuntimeSnapshot::remember('acme:plans', fn () => AcmePlan::orderBy('price')->get()->toArray());

The value stays in worker memory for at most 60 seconds, and every worker drops it as soon as the runtime version changes. Every admin save (any non-GET request under /admin/*) and every Setting write changes it, so saving your settings page refreshes it everywhere. A webhook, job or command that changes the data should call RuntimeSnapshot::bump() itself.Store arrays, not model instances, and never per-user data: the snapshot is shared by everyone the worker serves.

Event::listen(), View::composer() and afterResolving() add to dispatchers that outlive the request. Called from a controller or middleware, they pile up, run several times and make every later request slower. Register them in your provider.

With GUEST_PAGE_CACHE=true, signed-out visitors to a short list of public routes get a cached copy of the page. The list is in config/page_cache.php and already includes some module pages (news.index, knowledgebase.index, custom-pages.show, status.public). Your routes are only cached if they’re on it. A route on the list must render the same for every guest, with nothing taken from the visitor’s IP, cookies or query string, and no side effects such as view counters.

Checking your work

php artisan module:doctor AcmePanelService

It validates your manifest, your composer.json, that your provider loads, your permissions block, and every convention class core will look for: does it exist, is it static or instance, does it take the arguments core passes, does it implement the right interface. It exits non-zero on errors so it works in CI. --strict also fails on warnings. Then check by hand:

module:list shows it enabled

Tables exist with your prefix

Settings page loads and saves

Credentials encrypted, column is TEXT

Failures throw or log at error

It works after php artisan octane:reload, on the first request and on the ones after it

Two customers in a row each see only their own data

Disabling the module leaves the app working

When it doesn’t work

What you see	What it usually is
Your change isn’t showing up	Octane hasn’t reloaded. Run `php artisan octane:reload`, plus `queue:restart` for queued code
New route returns 404 or 405	Same thing: routes are registered when a worker boots
Enabled from the command line, the site still acts as if it’s off	Same thing: reload after `module:enable`
Copied a module in, it’s missing from Admin, Modules	Run `composer dump-autoload`, then reload. Workers scan `Modules/` at boot
Edited `modules_statuses.json`, nothing changed	Statuses live in the `module_statuses` table
Every request fails after enabling or reloading	An enabled module’s provider isn’t autoloadable. See If you have already broken it
Right on the first request, wrong afterwards, or one customer sees another’s data	Request state in a static or singleton, or per-request work in `boot()`
A shared Inertia prop vanishes after the first page	`Inertia::share()` in a provider. Move it to middleware
Feature does nothing at all	Class name is wrong. Run `module:doctor`.
`Class not found` after adding a file	Needs `composer dump-autoload`, then a reload
Inertia page not found	`register.ts` key doesn’t match `Inertia::render()`, the `../` count is off, or you haven’t run `npm run build`
Admin route 403s for a real admin	Permission node has no category, or `routes` included the `/admin` prefix
Permission can’t be ticked in the role editor	Same: no category, so it’s superadmin only
Gateway missing at checkout	`getConfig()['enabled']` is false, or you didn’t call `flushPaymentGatewayCache()`
Module not found at all	Directory doesn’t match `category`, or invalid `module.json`
”Provisioned” but nothing exists	Something caught the error and returned success. Throw instead.
Duplicate emails or log rows	Missing `configureEmailVerification()`, or you listed a core listener
Cron job stopped	You overrode `registerCommandSchedules()` instead of using `moduleSchedule()`

GETTING STARTED

MAKE YOUR OWN

SPARTAN THEMES

Where modules live

module.json

The service provider

What the base does for you

Hooks you can override

RouteServiceProvider

Route files

Admin permissions

Admin settings with no frontend work

Field types

Tabs

Test connection

Status cards

Two helpers you get for free

resolveSecret()

flushPaymentGatewayCache()

Credentials

Migrations

Events

Frontend pages

Enabling a module

The autoloader trap

If you have already broken it

Installing a module

Updates keep your modules

Running under Octane

Making changes live

Code that’s safe in a long-lived worker

Checking your work

When it doesn’t work

​Where modules live

​module.json

​The service provider

​What the base does for you

​Hooks you can override

​RouteServiceProvider

​Route files

​Admin permissions

​Admin settings with no frontend work

​Field types

​Tabs

​Test connection

​Status cards

​Two helpers you get for free

resolveSecret()

flushPaymentGatewayCache()

​Credentials

​Migrations

​Events

​Frontend pages

​Enabling a module

​The autoloader trap

​If you have already broken it

​Installing a module

​Updates keep your modules

​Running under Octane

​Making changes live

​Code that’s safe in a long-lived worker

​Checking your work

​When it doesn’t work

Where modules live

module.json

The service provider

What the base does for you

Hooks you can override

RouteServiceProvider

Route files

Admin permissions

Admin settings with no frontend work

Field types

Tabs

Test connection

Status cards

Two helpers you get for free

Credentials

Migrations

Events

Frontend pages

Enabling a module

The autoloader trap

If you have already broken it

Installing a module

Updates keep your modules

Running under Octane

Making changes live

Code that’s safe in a long-lived worker

Checking your work

When it doesn’t work