File Structure for a Application

Augustin Delaporte
General Manager China
11 Feb 2015 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 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 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:

... supports deploying multiple applications inside the same Git repository, which means a  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 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, 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

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, Routes are descriptions of incoming URLs and what 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 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.