One source, many apps

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.

Unified what now?

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.

Submodules are easier

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.

Now, the .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.

Applications can reuse code

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 source.root value.

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 /apiapp.

- 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.

Go forth and be flexible

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.