How to kickstart a new Laravel Application with DDEV in 2026?
In 2025 I kickstarted my first real Laravel project. Along the way I noted the needed steps that are (from my perspective) crucial to have like a solid foundation.
Now in the beginning of 2026 I’m about to build the next project based on Laravel and I compiled the following list. It made my development - especially the initial steps creating a new application - a lot easier. Helping me to reach the fun part of development quicker - and I hope this helps someone else, too!
Prepare local development environment
Among Laravel delopers, Laravel Herd seems to be pretty popular as the base for PHP based development. But somehow I didn’t like it and stuck with DDEV.
While there’s no need to argue whether the one or the other is better for whatever reason, I want to mention why I prefer DDEV for now: The whole development environment is running within Containers, making it easy to start from scratch, share the config among team-mates - and second: I’m just too used to it after using it for years…
Needed steps:
- install ddev (see ddev documentation)
- install/kickstart Laravel (see Laravel documentation)
- check the kickstarted code for things that are obviously not needed (but don’t blindly remove everything like e.g. the “user table migration” when your application won’t use users - but the migration contains the session table which is crucial for the framework to function…)
Version and Automate…
I tend to pretty early on create a project on my Gitlab instance and keep everything related to that project in there.
With Gitlab CI I automate both tests to run on each commit - and also use Renovate Bot to periodically scan the repository and automatically propose updates to the used software components.
Needed steps:
- create Git-Repository at the place where you keep your Git repos
- add CI config to run automated tests (build, codestyle, SAST and tests for the functionality)
- add + enable config for Renovate Bot to keep your project updated automatically
Frontend
Next is a part that costs me more nerves and time almost every time I develop something: Decide about both the technical and the visual frontend stack. Modern “best practice” seems to be a consensus that it needs to be multi-layered and rather complicated with a frontend-build pipeline that compiles both Typescript to Javascript and CSS artifacts resulting in a separate frontend application that then talks to the backend over APIs.
Fine.
But rather often I think that’s overkill for what I build. So my approach so far is to keep things simple as long as possible. For the current project this means to go along with simple Blade-Templates that render HTML output - and some CSS for styling. Depending on the CSS framework to use I still use npm and e.g. vite to automatically fetch/install the needed frontend components as a dependency.
For the latest project I chose the Pico CSS framework.
Needed steps:
- decide on frontend architecture (technical)
- choose CSS framework (or write own rules from scratch)
- review both
composer.jsonandpackage.jsonfor installed but eventually not used package dependencies, remvoe what’s not needed - remove Laravel’s “Welcome-Blade” including it’s route and replace it with your own Front-Page / Dashboard of your application
- abstract your frontend template to a “Base Template” and “per view templates” (so e.g. the header/footer can be shared among different views and changed at one single location)
Documentation for your future self
Especially for hobby-projects I tend to work on them in waves: Do a lot of stuff, then let it lay around for weeks or months, then work on it again for a period of time, …
Having a developer-focused documentation is crucial for me to avoid frustration. So I start to write a README.md for new projects pretty early on and take note especially on the development environment and how to set it up again if needed. Thanks to DDEV that’s usually just a git clone followed by a ddev start - and some other steps like seeding your database with dummy data, the URL to the local DEV-Environment, …
Needed steps:
- write a
README.mdfile - describe how to set-up the local development environment
- describe how to seed the database, run tests, where to reach the local DEV frontent
- describe how the deployment works
- destroy your local DEV environment - follow your documented steps to verify it really works
Deploy early
Having the application locally is nice. But usually no one else can look at it, test it, give feedback, enjoy it, …
For me it’s crucial to deploy early on. And be it just to a staging environment that’s semi-public (e.g. public webserver but only reachable after authentication).
I usually do that within Gitlab CI and deploy to one or multiple environments. For the Laravel based projects I use Deployer to orchestrate the deployments.
Needed steps:
- get/prepare a webserver
- add / test your deployment config in a CI job
- set a Favicon in your frontend-output (to avoid that “each and every” application has the Laravel default Favicon)
- set the needed DNS entries to point to your webserver
- test to reach your application
- share the link with your friends so they can look at what you’ve built
Tracking
I’m a curious guy and want to see if and how my applications are being used. For this I usually just create a new site in my Matomo installation and add the tracking-code to my application’s frontend output.
Of course Google Analytics and other solution can do the trick, too. But I prefer having those tracking data on a server I operate myself. The screenshot obviously shows the state right after initial deployment for an application that is not publicly reachable yet.
Needed steps:
- choose which tracking tool to use
- add site/tenant/tracking-id (whatever it’s called in your tool of choice)
- add tracking code to your application
- enjoy whenever your application is being used
What’s missing?
I hope this short summary helped to not miss anything. What’s your proces and what am I maybe missing in the above list? Please let me know, I’m curious!