• Overview
    • Django
    • Next.js
    • Drupal
    • WordPress
    • Symfony
    • Magento
    • See all frameworks
    • Observability
    • Auto-scaling
    • Marketing Teams
    • Retail
    • Higher Education
  • Pricing
  • Featured articles
    • Switching to Platform.sh can help IT/DevOps organizations drive 219% ROI
    • Organizations, the ultimate way to manage your users and projects
  • Support
  • Docs
  • Contact
  • Login
  • Free Trial

File Structure for a Platform.sh Application

February 11, 2015
Augustin Delaporte
Augustin Delaporte
VP Product

Platform.sh offers a deterministic approach to deploying applications. That means that the contents of your Git repository will determine exactly how infrastructure will get orchestrated, including what running services are available, and what scripts need to run during the building of your applications.

The deterministic magic that makes this all happen is a file called  .platform.app.yaml which defines the properties of an application. You can create a version of this file for each application you’re deploying, in the root directory for that app in your Git repository.

This blog post shows how to structure your Git repository, and discusses the Platform.sh-specific files that are needed, as well as where your application code fits into that.

Define your application(s)

The structure of a Git repository for a single application is structured like this:


Platform.sh supports deploying multiple applications inside the same Git repository, which means a  .platform.app.yaml  needs to be placed in the root directory of each of your applications.

Here is an example a Drupal app and a Symfony app together:


Read more about .platform.app.yaml file in our documentation.


You can find many working examples in our Github repository.

Services and Routes

Two additional configuration files allow you to define what services you want to deploy for each application and what routes will serve your applications.


In Platform.sh, each service (MySQL, Solr, Redis, ElasticSearch…) runs within a specific isolated container. These containers get orchestrated into virtual clusters that comprise your application. You list which services you need, and how they’re configured, within the special  services.yaml  file in your Git repository. The services will be provisioned when you  git push  to Platform.sh.

Services are defined via a configuration file:  .platform/services.yaml . The file describes a list of services, including what version when multiple versions are available, and how much persistent storage should be allocated to that service.

Read more about .platform/services.yaml file in our documentation.


In Platform.sh, Routes are descriptions of incoming URLs and what Platform.sh should do with them, including sending them to an application, or redirecting them. Routes also specify how the web server should handle caching, and whether Server Side Includes are to be used.

Routes are defined via a configuration file:  .platform/routes.yaml . Routes can also be defined via the Platform.sh web UI. The  {default}  placeholder in any Route always gets expanded to whatever the default domain for the current environment.


If you update your Routes via the Web UI, you will need to  git pull  to see the updated  .platform/routes.yaml  file.

Read more about .platform/routes.yaml file in our documentation.

Get the latest Platform.sh news and resources

Related Content

Cover image

A series of unfortunate commits: notable software security stories

AboutSecurity and complianceTrust CenterBoard and investorsCareersPressContact us
Leader Winter 2023
System StatusPrivacyTerms of ServiceImpressumWCAG ComplianceManage your cookie preferencesReport a security issue
© 2023 Platform.sh. All rights reserved.
Supported by Horizon 2020's SME Instrument - European Commission 🇪🇺