The flexibility of Platform.sh has always been one of its strong points. We want you to be able to build your application the way you want, focused on the details that do matter to you and not the details that don’t.
Today, we’re happy to announce a new articulation point: unified application definitions.
Previously, you could put multiple discrete codebases in a single project if they together formed a coherent application. That could be a front-end and separate backend application, a main application and an API gateway, a main application and a dedicated queue worker, or many other configurations that our customers have come up with, all in different languages.
The requirement was that each application be defined by its own
.platform.app.yaml file, and be in its own directory, along with the code that went with it. That precluded using the same codebase twice for different web-facing apps within the same project. We’ve long supported “worker” containers, which allow for the exact same build with a different
start command, but not multiple web frontends or alternate builds.
So we fixed that.
.platform.app.yaml files can now specify a
source.root parameter. It defaults to the directory the
.platform.app.yaml file is in, but the parameter can be any directory in the project.
source: root: /path/to/code
That has two main benefits.
We’ve always supported Git submodules in projects, but the
.platform.app.yaml file had to be in the main repository. That sometimes led to awkward file path configurations when using submodules.
.platform.app.yaml file still has to live in the main repository, but it can simply specify a
source.root value of the path to the submodule. All other paths will be evaluated relative to that, making it much easier to configure.
It also means multiple applications can use the same codebase. This becomes easier when paired with the new ability to put multiple application definitions into a single
.platform/applications.yaml file. The
applications.yaml file’s contents are a YAML array of application definitions, exactly the same as
.platform.app.yaml. They can be as similar or different as you like, but can have the same
For example, here’s an
applications.yaml that creates two different application containers off of the same codebase stored in
/mainapp. Each one has a different
passthru value and name; the
admin container will be forced to a “small” container as it will have less traffic. It also builds a Go application off an entirely separate codebase in
- name: api type: golang:1.14 source: root: apiapp hooks: build: | go build -o bin/app web: upstream: socket_family: tcp protocol: http commands: start: ./bin/app locations: /: allow: false passthru: true - name: main type: "php:7.4" source: root: mainapp web: locations: "/": root: "web" passthru: "/index.php" - name: admin type: "php:7.4" size: S source: root: mainapp web: locations: "/": root: "web" passthru: "/admin.php"
You’re welcome to vary the configuration even more if you prefer, even the build hook.
The result in this case will be three separate applications with unique names that you can route to from
routes.yaml, all coming from the same source files on disk. The applications don’t have to be of the same type or version, as each will be built and deployed separately.
If any of that sounds exciting, you can start using it right away.
applications.yaml is now available on all projects, so experiment and find new ways to build your dream application.