Connect a Laravel app

DevDojo Sites can be the visual marketing layer for your Laravel app. Your marketing routes (/, /pricing, /about) are designed and edited in Sites; your application routes (/login, /dashboard) stay normal Laravel. When you publish in Sites, the pages land in your app and render as real, native Blade — not an iframe, not a static snapshot.

Requires the devdojo/devdojo Composer package in your Laravel app. It builds on devdojo/pocketknife, which renders the Sites Blade dialect natively.

#1. Install

In your Laravel application:

composer require devdojo/devdojo

Not on Packagist yet. While devdojo/devdojo and its devdojo/pocketknife renderer are in private release, add both to your app's root composer.json repositories first (a GitHub token with read access is required), then run the command above. See the package README for the exact block.

#2. Get a connect token

In DevDojo Sites, open your site's Settings → Connect a Laravel app and Generate a token. You'll see an sk_live_… token once — copy it now; it isn't shown again. (You can revoke it anytime from the same screen.)

#3. Connect

Back in your app:

php artisan devdojo:connect sk_live_xxxxxxxxxxxxxxxxxxxx --url=https://devdojo.com

--url is the DevDojo control plane your site lives on — https://devdojo.com for production, or your own host for local/staging. (The Settings screen shows the exact command, already filled in, for your site.) It defaults to https://devdojo.com if omitted.

This validates the token, names the connected site, and stores the connection in your .env (DEVDOJO_TOKEN, DEVDOJO_PROJECT, DEVDOJO_URL).

#4. Pull the site

php artisan devdojo:pull

Your published pages, layouts, components, and assets are written into storage/app/sites and served automatically. Visit / (or any page your site publishes) in your app — it's live. Your own routes always win, so nothing your site publishes can shadow your application.

Re-run devdojo:pull any time you republish in Sites — it's hash-diffed, so only what changed is written.

Only safe Blade is served. Because your app renders these pages as real Blade, DevDojo Sites will refuse to hand over a site that uses constructs the visual builder's sandbox can't run safely (@php, raw PHP, unknown directives). If a pull reports the site can't be served, fix the flagged files in DevDojo Sites, republish, and pull again.

#The commands

#Deploying

The pulled directory (storage/app/sites) is not committed to git — it's content, not code. Run php artisan devdojo:pull as part of your deploy (in your build or release step) so production gets the latest published site. That's the same command you run locally; on a fresh checkout it fetches everything.

Order matters on cached deploys. If your deploy runs php artisan config:cache, run devdojo:connect / devdojo:pull before it so the cached config picks up the connection. The commands read your .env directly as a fallback, so a first pull still works — but caching last keeps serving fast.

The same applies if you reconnect to a different site or URL on a config-cached app: the CLI recovers the new connection from .env, but your running app keeps serving the old one until you rebuild the config cache (php artisan config:cache). devdojo:connect warns you when it sees a cached config.

#Taking a page over ("eject")

Because Sites publishes real Blade, any page can become yours: copy it out of storage/app/sites/resources/views/pages/ into your app's own resources/views/ and add a route. From that point it's ordinary Laravel — add @auth, Livewire, middleware, whatever you need. "Start with a marketing site, grow into an app" is literal here.

#What stays private

Your site's content is fetched over a scoped, revocable token — only that one site is ever exposed, and only its published source. Provider keys, other sites, and your DevDojo account never cross the boundary.