Symfony Starter
IntermediateWeb AppPHP Symfony with Doctrine, Twig templates, and a long-term support release cycle.
Published 14 October 2026
About Symfony Starter
Symfony is the PHP framework for applications that are meant to last. The Symfony Starter stack pairs it with a relational database and a managed hosting platform or your own server, and gives you a framework built from decoupled components, an explicit, configuration-driven style, and a release policy with long-term support versions every two years. It suits teams that value predictability and strict structure over the fastest possible first week.
A typical project is server-rendered with Twig, a templating language with automatic output escaping, and uses Doctrine to map database tables to PHP classes and manage migrations. Symfony Flex installs and configures packages from recipes, the Security component handles login, roles, and access rules, and Messenger moves slow work onto queues. Symfony UX adds Stimulus and Turbo for interactive pages without writing a single-page app, and can mount Vue or React components inside Twig templates where a page needs more.
PostgreSQL is the default database, the one the Doctrine recipe sets up for new projects, with MySQL and MariaDB as supported options. Doctrine abstracts the differences, so they work the same way when a host or team already runs them. The app runs as PHP-FPM behind a web server or as a container, which most hosts support.
Many PHP projects already depend on Symfony code, since Laravel, Drupal, and Composer use its components. Starting from the full framework is a good fit for business applications, internal tools, and API backends that will be maintained for years by a team.
Key Features
- ✓Symfony framework built from decoupled components, with long-term support releases every two years
- ✓Doctrine ORM and migrations for mapping PostgreSQL or MySQL tables to PHP classes
- ✓Twig templating with automatic output escaping and template inheritance
- ✓Symfony Flex recipes that install and configure packages, with Maker for generating code
- ✓Security component with authenticators, voters, and role-based access control
- ✓Messenger for queues and async handlers, with Redis, RabbitMQ, or database transports
- ✓Symfony UX with Stimulus and Turbo for interactive server-rendered pages
- ✓Form component with built-in Bootstrap and Tailwind form themes
When to Use Symfony Starter
- →Internal business tools and admin back offices maintained by a PHP team over many years
- →Multi-role web applications with fine-grained permissions
- →E-commerce and content platforms that build on Symfony-based projects such as Sylius or Drupal
- →Applications that need queues, scheduled work, and clear service boundaries
- →API backends with a server-rendered admin interface
Pros
- Explicit configuration and strong typing keep large codebases understandable as teams change
- A predictable release and deprecation policy with long-term support versions reduces upgrade risk
- Components can be adopted one at a time, so existing PHP code can move over gradually
- Mature tooling, including the debug toolbar and profiler, shortens the time to find slow queries and bugs
Cons
- More configuration and concepts to learn up front than Laravel, so the first week is slower
- More boilerplate for small projects and quick prototypes
- A smaller pool of beginner tutorials and starter kits than Laravel
- Pages reload on every navigation unless Symfony UX, HTMX, or a JavaScript frontend is added
Database Options for Symfony Starter
The default: the database the Doctrine recipe's Docker Compose file starts, with strong support for complex queries, JSON columns, and constraints. Doctrine talks to it through the pdo_pgsql driver, and migrations, entities, and repositories look the same on any supported database. Run it yourself or use a managed instance from your host.
The classic pairing with PHP and the database most shared PHP hosts offer by default. Doctrine treats it as a vendor choice, not an architecture change: the same entities and migrations run unchanged. Pick it when your host, team, or existing tooling is already MySQL-centric.
A MySQL-compatible fork with fully open licensing and the default on many Linux distributions and hosts. Doctrine supports it through the same MySQL driver family, so the choice is about what your host runs. Pick it over MySQL when that is what your server already provides.
These are highlighted picks. To see all the tools, check the Databases category.
Hosting Options for Symfony Starter
A container platform where the Symfony app deploys as a persistent service, a natural fit for PHP-FPM or FrankenPHP holding live database connections. The Hobby plan costs $5 a month and includes $5 of usage, billed per CPU and memory. Auto-deploys on push, and there is no CDN of its own.
Deploys the app as a Docker-based web service with built-in cron jobs, private networking, and managed PostgreSQL. The free instance sleeps when idle, so an always-on app starts at $7 a month. A good fit for a Symfony app that wants managed Postgres next to it on the same platform.
A self-managed VPS running PHP-FPM with a web server, or a Docker setup such as the Symfony Docker template, at the price of handling deployment, TLS, and updates yourself. A 2 vCPU, 4 GB server costs about €5.49 a month, the cheapest option here, and has plenty of room for the app, its database, and a queue worker.
Runs the Symfony app as a container close to users across several regions, useful when latency to a spread-out audience matters more than cost. Machines are billed per second, with a 2 GB shared machine around $11.83 a month, and a separate worker machine can run the Messenger consumer.
These are highlighted picks. To see all the tools, check the Hosting & Cloud category.
Symfony Starter Add-ons
Each addition below extends this stack with a capability the base stack works fine without. None are required: include the ones your product actually needs when building this stack, and skip the rest.

App features and services
4
What your users see and use: sign-in, payments, email, and the look and feel of the interface.
Email Add-ons
Add email when the app needs to send account verification, password reset, or notification messages.
A transactional email API for account verification, password resets, and notifications, used through Symfony Mailer's official Resend bridge by setting a single DSN. A free tier covers early development.
The established high-volume option, with dedicated IP addresses and deliverability tooling, through Symfony Mailer's official SendGrid bridge. No permanent free plan, so it earns its place when volume and deliverability matter more than upfront cost.
Payments Add-ons
Add payments when the product is ready to charge for subscriptions or one-time purchases.
Subscriptions and one-time checkout through Stripe's hosted Checkout, using the official stripe-php library in a controller or service. Symfony has no first-party billing package, so webhook handling and customer records are written in the app, with Messenger a good place to process webhook events. The stack works fully without it.
Styling Add-ons
Add styling when you want a component or utility-class system to build the UI faster than hand-writing CSS from scratch.
Utility classes written directly in Twig templates, with the Tailwind bundle or Symfony AssetMapper handling the build. Symfony's Form component also ships a Tailwind form theme. The stack works with plain CSS by default, and this is one of two styling systems to choose from, usually not both.
Ready-made components and a grid for Twig templates, with Bootstrap 5 form rendering built into Symfony's Form component through a single form theme setting. A fast route to a consistent admin or business interface with little custom CSS. Choose it or Tailwind, since the two overlap on spacing and layout classes.
These are highlighted picks. To see all the tools, check the CSS Frameworks category.
Interactivity Add-ons
Add client-side interactivity when you want local UI state — toggles, modals, dropdowns, tabs — without a full JS framework or an extra server round trip.
Server-rendered fragments swapped into the page from ordinary Symfony controllers returning Twig partials, so a page updates without a full reload and without a JavaScript build. A lighter alternative to Symfony UX Turbo for teams that already know HTMX.
These are highlighted picks. To see all the tools, check the HTML-first Frameworks category.

Under the hood (backend)
3
Services your users never see, which store data and keep the app fast and reliable.
Object Storage Add-ons
Add object storage when your app accepts file uploads or produces files, such as avatars, documents, images, and exports, and those files should live outside your database and server disk.
S3-compatible object storage with no egress fees, used from Symfony through the Flysystem bundle's S3 adapter with a custom endpoint, so uploads and exports are stored outside the app server. The 10 GB free tier covers an early product.
The reference object store and the API the others copy, with the most storage classes, regional controls, and lifecycle rules, used through the Flysystem bundle's S3 adapter. It fits best when the rest of the app already runs on AWS, though data transfer out is billed.
These are highlighted picks. To see all the tools, check the Object Storage category.
Caching Add-ons
Add caching when the same reads or computations repeat and you want them answered from memory: a cache holds hot data, shared counters, and session state in front of a database or an upstream API.
Symfony's Cache component has a Redis adapter, so cache pools, sessions, and Messenger's Redis transport can share one server. Caching expensive Doctrine queries and rendered fragments is the first step, and PostgreSQL already keeps hot rows in memory, so Redis pays off once traffic or slow queries justify it.
Background Jobs Add-ons
Add background jobs when work should run outside the request and must survive restarts, retry on failure, or run on a schedule: a separate worker takes it from a queue. Small fire-and-forget jobs can often stay in your framework's built-in background tasks.
Messenger's AMQP transport sends messages to RabbitMQ and runs consumers as worker processes, for emails, imports, and webhooks that should not block a request. Messenger can also use Redis or a Doctrine database table as a transport, which needs no extra service, so RabbitMQ fits when queue volume or routing needs grow.
These are highlighted picks. To see all the tools, check the Message Queues & Background Jobs category.

Build and deploy
2
Testing, packaging, and shipping your code on every change.
CI/CD Add-ons
Add CI/CD when you want a dedicated pipeline for running tests, linting, or multi-stage builds before a deploy goes out. Many hosting platforms already redeploy automatically on every push on their own — a CI/CD tool adds the most value on top of that by gating the deploy on a passing test suite, and matters even more when the hosting choice does not auto-deploy at all, such as a self-hosted server.
Runs PHPUnit tests, static analysis, and coding-standard checks on every push, then triggers a deployment, from the same GitHub repository the code lives in.
These are highlighted picks. To see all the tools, check the CI/CD Pipelines category.
Containerization Add-ons
Add containerization when you want the app packaged the same way across local development, staging, and production, or need to deploy somewhere that isn't a managed serverless platform.
These are highlighted picks. To see all the tools, check the Containerization category.

Monitoring and analytics
2
For you rather than your users: what people do in the app, what breaks, and why a model answered the way it did.
Observability Add-ons
Add observability when you want to catch errors and performance regressions in production before users have to report them.
These are highlighted picks. To see all the tools, check the Infrastructure & APM category.
Analytics Add-ons
Add analytics when you want to measure traffic, track visitor behavior, or understand how people actually use the product.
Event tracking, session replay, feature flags, and A/B testing in one platform, with an official PHP library for server-side events from controllers and Messenger handlers. The richest feature set if you want more than pageviews.
These are highlighted picks. To see all the tools, check the Web & Product Analytics category.
Frequently Asked Questions about Symfony Starter
How does this compare to the Laravel Starter stack?
Both are full-stack PHP frameworks with an ORM, a template engine, queues, and a command line, and Laravel itself is built on Symfony components. Laravel Starter is more opinionated and faster to start, with a larger pool of tutorials and first-party packages for billing, search, and authentication. This stack asks for more configuration up front and rewards it with explicit structure, a predictable upgrade path, and a looser coupling between parts, which suits large codebases and long-lived business systems. Pick Laravel to ship quickly with a small team, and Symfony when the application will be maintained for years or must fit into an existing Symfony or Drupal ecosystem.
Can I use a JavaScript frontend with Symfony?
Yes, in two different ways. The lighter one keeps Twig in charge of the page: the Symfony UX Vue and React packages mount a component inside a Twig template and pass it props from the controller, so one dynamic part of a page can use a JavaScript framework while routing, forms, and security stay on the server. The heavier one drops Twig for the interface and makes Symfony a backend API, often built with API Platform, behind a separate Vue, React, or Next.js app. That is a different architecture: two codebases and two deployments, token or cookie authentication across them, CORS to configure, and a data contract to maintain. Choose it when a mobile app or other client will share the backend, or the interface is complex enough to justify its own app. Otherwise start with Twig, Symfony UX, and HTMX or Alpine.js, and add components where a page needs them.
Should I use PostgreSQL, MySQL, or MariaDB?
PostgreSQL is the default: the Doctrine recipe's Docker Compose file starts it, it leads MySQL in developer surveys, and it handles complex queries and JSON columns well. Doctrine hides most differences, so MySQL or MariaDB are a vendor choice, worth it when your host, team, or existing tooling already runs them. Decide before you write migrations, because Doctrine generates database-specific SQL and moving later means regenerating them.
Which Symfony version should I start on?
For an application that will live for years, use the current long-term support release, 7.4, which gets bug fixes until November 2028 and security fixes until November 2029. The newest 8.x release has the latest features but a shorter support window, and it expects you to upgrade every six months. A new LTS is published every two years, so plan an upgrade to the next one before 7.4's bug fixes end. Symfony deprecates features across minor versions, so fixing deprecation warnings as they appear keeps each upgrade small.
What's the cheapest way to run this stack?
A single small VPS runs the app, a self-hosted PostgreSQL, and a Messenger worker for about €5 a month, and every addition tool here has a free or open-source path. A managed platform costs more but removes server work: expect about $5 to $12 a month for the app, plus managed PostgreSQL from around $15 if you do not host it yourself. The part people forget is the queue worker, which runs as a second process and needs its own container or service on a platform host.
Stacks Related to Symfony Starter
Laravel Starter
ProjectPHP Laravel with Eloquent ORM and Blade templating.
Flask + HTML Templates
ProjectFlask with Jinja2 templates: lightweight Python web development.
HTMX + Laravel
ProjectLaravel Blade templates enhanced with HTMX: PHP interactivity without writing JavaScript.
HTMX + Flask
ProjectFlask routes with HTMX: server-driven interactivity without a JavaScript build pipeline.
Scores
Popularity3/5
Symfony is one of the two dominant PHP frameworks and its components sit inside Laravel, Drupal, and Magento, but the full framework has a smaller community of new developers than Laravel. Strong in enterprise and agency work, less visible among beginners and startups.
Learning Curve4/5
Dependency injection, bundles, Flex recipes, and Doctrine all need to be understood before building anything non-trivial. The documentation is thorough, but the entry point is steeper than in Laravel.
Flexibility4/5
Every part of the stack can be swapped or used on its own, from the ORM to the template engine, and the database can be PostgreSQL, MySQL, or MariaDB without changing application code. Structure is left to the developer rather than prescribed.
Performance4/5
Compiled service containers and cached configuration give fast production performance, and PHP-FPM or worker-mode runtimes scale well for typical web workloads. Development mode is slower because of the debug tooling, and server-rendered pages mean a full reload per interaction unless Symfony UX or HTMX is added.
Portability4/5
Symfony is open source and runs on any PHP host or container, and Doctrine works against several databases with the same entities. The main migration cost is the framework's own conventions, services, and Doctrine mappings, not a vendor.
Tools in the Symfony Starter Stack
Backend Frameworks
Add-ons (optional — add any, or none)
Payments
Styling
Interactivity
Object Storage
Caching
Background Jobs
CI/CD
Containerization
Observability
Analytics
Symfony Starter Pricing
Symfony, PHP, and PostgreSQL or MySQL are open source and free; your costs are hosting the application and running the database. A small VPS or platform service runs a Symfony app for about $5 to $12 a month, and managed PostgreSQL starts around $15 a month if you do not self-host it.
Symfony, PHP, and PostgreSQL, MySQL, or MariaDB are free.
Railway Hobby at $5 including usage, Render at $7, a Hetzner VPS at about €5.49, or Fly.io around $12; free tiers exist for testing.
Self-host for free, or use a managed instance from about $15 a month.