Symfony
sponsored by SensioLabs
Menu
  • About
  • Documentation
  • Screencasts
  • Cloud
  • Certification
  • Community
  • Businesses
  • News
  • Download
  1. Home
  2. Documentation
  3. SymfonyCloud
  4. Platform.sh, the Official Symfony PaaS
Search by Algolia
  • Platform.sh, the Official Symfony PaaS
    • The Basics
    • The Workflow
    • Getting Help
    • What's Next?
  • Getting Started
    • Installing the Symfony CLI Tool
    • Deploying a Project on Platform.sh
    • Working on a Project
  • Configuration
    • Hooks
    • Cron Jobs
    • Workers
  • Environment Variables
    • Platform.sh Environment Variables
    • Emails
    • HTTP
    • MySQL/MariaDB
    • PostgreSQL
    • Redis
    • Memcached
    • Elasticsearch
    • Solr
    • RabbitMQ
    • MongoDB
    • InfluxDB
    • Kafka
  • Troubleshooting
    • How to access the Application Logs?
    • Oops! An Error Occurred

Platform.sh, the Official Symfony PaaS

Edit this page

Platform.sh, the Official Symfony PaaS

If you are looking for the best way to host your Symfony projects, test Platform.sh, the Official Symfony PaaS.

Symfony provides a tight integration with Platform.sh, based on conventions to reduce configuration and make developers more productive.

You can think of Platform.sh as being the hosting framework part of Symfony. It abstracts your project infrastructure and manages it for you: never install nor configure services like a Web server, a MySQL database, or a Redis cache again.

Platform.sh is built on one main idea: your server infrastructure is part of your application, so it should be version controlled along with your application.

Every branch you push to your Git repository can come with bug fixes, new features, and infrastructure changes. Everything can then be tested as an independent deployment, including the application code and all services with a copy of their data (database entries, search index, user files, ...).

It really is "what would my site look like if I merge these changes to production?".

The following sections introduce the main concepts and how Symfony projects are deployed on Platform.sh.

The Basics

On Platform.sh, a project is linked to a Git repository. A project is composed of one or more applications. An application is a directory in your Git repository with a specific Platform.sh configuration and dedicated HTTP endpoints (via the .platform.app.yaml file).

Projects are deployed in environments. An environment is a standalone copy of your live applications which can be used for testing, Q&A, implementing new features, fixing bugs, ...

Every project you deploy on Platform.sh is built as a virtual cluster, containing a series of containers. The main branch of your Git repository is always deployed as a production cluster. Any other branch can be deployed as a production, staging, or development cluster.

There are three types of containers within your cluster, all configured by files stored alongside your code:

  • The Router, configured in .platform/routes.yaml, is a single nginx process responsible for mapping incoming requests to an Application container, and to optionally provide HTTP caching.
  • One or more Applications, configured via .platform.app.yaml files, holding the code of your project.
  • Some optional Services, configured in .platform/services.yaml, like MySQL/MariaDB, Elasticsearch, Redis, or RabbitMQ; they come as optimized pre-built images.

The Workflow

Every time you deploy a branch to Platform.sh, the code is built and then deployed on a new cluster.

The build process looks through the configuration files in your repository and assembles the necessary containers.

The deploy process makes those containers live, replacing the previous versions, with no service downtime.

Building the Application

During the build step, any dependencies specified in .platform.app.yaml are installed on application containers.

You can also customize the build step by providing a build hook composed of one or more shell commands that help creating your production code base. That could be compiling TypeScript files, running some scripts, rearranging files on disk, or whatever else you want. Note that at this point all you have access to is the filesystem; there are no services or other databases available. Your live website is unaffected.

The default build step for Symfony removes development front controllers, warms up the cache, compiles your assets, and more.

Once all of that is completed, the filesystem is frozen and a read-only container image is created. That filesystem is the final build artifact.

Deploying the Application

Before starting the deployment of your application, we pause all incoming requests and hold them so that there is no downtime.

Then, we stop the current containers and start the new ones. We then open networking connections between the various containers, as specified in the configuration files. The connection information for each service is available as environment variables.

As for the build step, you can define a deploy hook to prepare your application. Your application has complete access to all services, but the filesystem where your code lives is now read-only.

The default deploy step for Symfony replaces the current cache with the newly warmed up one and, for the web container, runs Doctrine migrations if any, and more.

Finally, we open the floodgates and let incoming requests through your newly deployed application. You are done!

Getting Help

If you are facing any issue with Platform.sh, submit a support ticket.

What's Next?

The documentation on symfony.com only describes the integration between Platform.sh and Symfony. For detailed documentation about Platform.sh, please refer to its official documentation. To benefit from the Symfony integration, use the Symfony CLI instead of the official Platform.sh one. The Symfony CLI wraps the Platform.sh one with added features related to Symfony so that you can replace platform with symfony when running commands from the documentation.

To get a feeling of what it looks like working with Symfony on Platform.sh, jump to the Getting Started guide.

This work, including the code samples, is licensed under a Creative Commons BY-SA 3.0 license.

↓ Our footer now uses the colors of the Ukrainian flag because Symfony stands with the people of Ukraine.

Avatar of Kévin LE LOUËR, a Symfony contributor

Thanks Kévin LE LOUËR for being a Symfony contributor

2 commits • 24 lines changed

View all contributors that help us make Symfony

Become a Symfony contributor

Be an active part of the community and contribute ideas, code and bug fixes. Both experts and newcomers are welcome.

Learn how to contribute

Symfony™ is a trademark of Symfony SAS. All rights reserved.

  • What is Symfony?
    • Symfony at a Glance
    • Symfony Components
    • Case Studies
    • Symfony Releases
    • Security Policy
    • Logo & Screenshots
    • Trademark & Licenses
    • symfony1 Legacy
  • Learn Symfony
    • Symfony Docs
    • Symfony Book
    • Reference
    • Bundles
    • Best Practices
    • Training
    • eLearning Platform
    • Certification
  • Screencasts
    • Learn Symfony
    • Learn PHP
    • Learn JavaScript
    • Learn Drupal
    • Learn RESTful APIs
  • Community
    • SymfonyConnect
    • Support
    • How to be Involved
    • Code of Conduct
    • Events & Meetups
    • Projects using Symfony
    • Downloads Stats
    • Contributors
    • Backers
  • Blog
    • Events & Meetups
    • A week of symfony
    • Case studies
    • Cloud
    • Community
    • Conferences
    • Diversity
    • Documentation
    • Living on the edge
    • Releases
    • Security Advisories
    • SymfonyInsight
    • Twig
    • SensioLabs
  • Services
    • SensioLabs services
    • Train developers
    • Manage your project quality
    • Improve your project performance
    • Host Symfony projects
    Deployed on
Follow Symfony
Search by Algolia