You can sell a Laravel module on the Lara Dashboard marketplace by building it as a normal Lara Dashboard module, setting
pricing in module.json, packaging it as a ZIP with php artisan module:zip, and submitting it from your laradashboard.com account. The marketplace handles payments, license keys and distribution, and its pricing page says sellers keep 95% of every sale.Disclosure: Lara Dashboard is our open-source, MIT-licensed Laravel CMS and admin, and we run the marketplace. This is our own guide. The technical details come from the repo's module development guide, the module packaging docs and the marketplace code in
app/Services/Modules, as of November 2026 (core v1.5.0, Laravel 13, PHP 8.3+).Quick answer: a sellable module is a normal module plus four extras
If you followed our post on how to build a Laravel module step by step, you already have most of what a buyer needs. To sell it, you add four things:
- A pricing type in module.json: free, paid or both
- A description.md file that explains what the module does
- Listing assets: a logo, a banner and screenshots
- A clean, versioned ZIP built for servers without Node
Then you sign in at laradashboard.com, open the marketplace, and use Submit Module. Buyers find your module either on the website or inside their own admin, on the Marketplace tab of the Modules page. Paid buyers get a license key, activate it on their domain, and receive updates through the same update checker that core modules use.
Why sell inside a platform instead of on your own site
You can sell a Laravel package on your own site. Many people do. But then you build the boring parts yourself: checkout, license keys, domain activation, a private download endpoint, update notifications and refunds. That is a product of its own.
A Lara Dashboard module skips most of that work, because the core already ships the buyer side:
Discovery inside the admin. The Modules page has a Marketplace tab, powered by the
MarketplaceModuleBrowser Livewire component. It calls /api/marketplace/modules on laradashboard.com and lists modules with search and type filters. Admins can install a module from there without leaving the dashboard.License activation. For paid modules, the module actions menu shows Activate License. The modal sends the key, the module slug and the current hostname to the marketplace's
/api/licenses/activate endpoint, then stores the license locally. The stored value goes through the core's sensitive settings handling, not plain text.Updates. The scheduler runs
modules:check-updates every hour. It sends installed module versions, the core version, the PHP version and the domain to the marketplace. When your new version is out, the buyer sees an update notice. For paid modules, the download request carries the license key in an X-License-Key header, so only licensed sites get the new ZIP.So you write the module, and the platform handles the store, the keys and the update channel. That is the trade we are offering.
Pick a pricing type that matches how buyers will use it
The
pricing field in module.json takes one of three values. It defaults to free.| Value | What the buyer sees | Good fit for |
|---|---|---|
| free | Install and use, no license needed | Small utilities, building a reputation, open-source work |
| paid | Activate License option, licensed updates | Complete business features like CRM, booking or billing |
| both | A free version plus a paid upgrade | Modules with a clear core and clear premium extras |
The field only says whether a license is needed. The actual plans, prices and tiers are set on the marketplace when you upload the module, not in
module.json. The guide is explicit about this.For a sense of what is listed today, the marketplace shows mostly free modules, such as DB Manager, Doc Forge and Custom Forms, plus paid ones like CRM at $99 per year and LaradashboardPro at $29 per year, as of November 2026. We cover what the CRM includes in our CRM module tour. We are not going to tell you what to charge. Look at what a buyer would otherwise build or pay for, and price below that.
Fill in the metadata buyers actually read
A listing is only as good as its metadata. These are the fields that matter for selling:
name and title.
name is a lowercase slug used for routes, status tracking and license matching. title is what buyers see. Do not rename the slug after you sell the first copy, because licenses and updates are tied to it.version. Use semantic versions like
1.2.0. The update checker uses version_compare() against the installed version, so a sloppy version string means buyers never see your fix.min_laradashboard_required. The boot code checks this before loading a module. Set it to the oldest core version you have tested, not to whatever you happen to run.
author, author_url, documentation_url, demo_url. Buyers want to know who stands behind the module and where the docs live. A demo URL sells better than any paragraph.
logo_image and banner_image. The docs recommend a 256×256 logo and a 1200×400 banner. The packaging docs also describe a
marketplace-assets/ folder with a logo, a banner and a screenshots/ folder.description.md. The module guide marks this file as required for marketplace submission. It is rendered as HTML on the listing, and it cannot be edited from the marketplace UI. To change it, you ship a new version. Write it like a sales page with honest limits: what it does, who it is for, what it needs, and what it does not do.
Package it so it installs cleanly on a stranger's server
Your module will run on servers you have never seen. The packaging tools are built for that.
Run
php artisan module:zip YourModule for a release. It runs composer install --no-dev, installs npm packages, compiles assets with Vite and Tailwind, checks the compiled output and writes a ZIP named like yourmodule-v1.2.0.zip. The ZIP includes a .module-manifest.json with the build time and the PHP and Laravel versions you built with.Because assets are pre-compiled into
dist/, the buyer's server never needs Node. When the ZIP is installed, assets are published to public/build-yourmodule/ automatically.The packager leaves out
.git, node_modules, tests, .env files, logs and editor folders. Still, open the ZIP and look. Secrets in a config file or a stray SQL dump will not be caught by an exclude list.Two more things from v1.5.0 worth knowing. First, module installs are now checked so a module's metadata cannot write files outside
modules/. Second, a module's vendor/autoload.php now loads after the core autoloader, so core classes always win. If you bundle your own copy of an illuminate/* package, it will not override the framework. Better not to bundle it at all. Both changes are in our v1.5.0 release notes.Submit, get reviewed, then ship versions
Submission happens on laradashboard.com. Sign in or create an account, open the marketplace, and choose Submit Module. You upload the ZIP and set your pricing plans there.
The marketplace describes its listings as security-reviewed, and the update code only offers versions that are marked approved and have a release date. So plan for a review step before your module or a new version goes live. Do not promise a buyer a fix "today" until it has been approved.
The public marketplace and pricing pages do not list payout schedules or methods. Read the seller terms in your account before you set prices, and ask us if anything is unclear. We would rather you know the terms up front than be surprised later.
After launch, every release follows the same loop: bump
version, write a changelog, run tests, build with module:zip, and upload. Buyers' sites pick it up on the next hourly check.Trade-offs: when not to sell on the Lara Dashboard marketplace
The marketplace is a good fit for some products and a poor fit for others. Be honest with yourself about which one you have.
- If your code works in any Laravel app, a normal Composer package reaches far more developers.
- If your buyers do not run Lara Dashboard, they cannot install a Lara Dashboard module.
- If you need custom licensing, such as per-seat pricing or offline keys, the built-in domain activation may not match.
- If the module is really a service you host, sell the service and ship a thin free connector module.
- If you cannot commit to updates for new core versions, sell it as a one-off client deliverable instead.
- The marketplace is young. Today it lists a handful of modules, so do not expect a large ready-made audience yet.
That last point cuts both ways. A small marketplace means less traffic, but it also means a good module in an empty category is easy to find. If you are weighing modules against a plugin ecosystem, our post on modular Laravel apps vs WordPress plugin spaghetti explains why we chose this structure.
Seller self-check before you submit
- module.json has the final name slug, a title and a semantic version.
- pricing is set to free, paid or both on purpose.
- min_laradashboard_required matches the oldest core version you tested.
- description.md says what it does, who it is for and what it does not do.
- Logo, banner and at least three screenshots are ready.
- Every route is behind auth and every action is checked by a policy.
- Feature tests pass, and pint has formatted the code.
- No dd, dump or debug logging is left in the code.
- The ZIP was built with module:zip and opened by hand to check its contents.
- The ZIP installs, migrates and enables on a fresh Lara Dashboard site.
- Migrations have down methods, so buyers can roll back.
- You have a changelog and a plan for the next core release.
Most of these come straight from the pre-release checklist in the packaging docs. The fresh-site install test is the one people skip, and it is the one that catches missing assets and wrong versions. Our post on staging, tests and CI for Laravel CMS work shows how to automate it.
Verdict: sell here when your buyers already run Lara Dashboard
Selling a Lara Dashboard module is mostly about the work you already do as a Laravel developer: good code, clear permissions, tests and a clean build. The platform adds checkout, license keys, domain activation, in-admin discovery and an update channel, and the pricing page says you keep 95% of each sale.
It is not a shortcut to a big audience yet, and it only reaches Lara Dashboard users. If that is your market, or you build for agencies and clients who use it, it is the least effort path from "it works on my site" to "people pay for it". Start by building one useful module, then explore the marketplace to see where it fits.
FAQ
How much of each sale does a module seller keep?
The laradashboard.com pricing page says sellers keep 95% of every sale, and that Lara Dashboard handles payments, licensing and distribution. Check the seller terms in your account for payout details.
Where do I set the price of my module?
On the marketplace, when you upload the module. The pricing field in module.json only says whether the module is free, paid or both. Plans and prices live on the marketplace.
How do buyers activate a paid module?
They open the module's actions menu in the admin and choose Activate License. The key is checked against the marketplace for their domain and then stored on their site.
How do buyers get my updates?
Lara Dashboard checks the marketplace for module updates every hour. When your approved version is newer than the installed one, the admin shows an update. Paid modules need an active license to download it.
Can I offer a free version and a paid version?
Yes. Set pricing to both in module.json. That fits a module with a useful free core and paid extras.
Can I sell the same module elsewhere?
Your code is yours, so check the seller terms for any exclusivity rules. In practice, a Lara Dashboard module only runs on Lara Dashboard, so the marketplace is where its buyers are.
