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:
.git/ .platform/ routes.yaml services.yaml .platform.app.yaml YOUR APPLICATION FILES ...
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:
.git/ .platform/ routes.yaml services.yaml drupal-app/ .platform.app.yaml YOUR DRUPAL FILES ... symfony-app/ .platform.app.yaml YOUR SYMFONY FILES ... ...
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
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:
Routes can also be defined via the Platform.sh web UI. The
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 pullto see the updated
Read more about .platform/routes.yaml file in our documentation.