Introducing a leaner and more flexible config (and support for custom hosts!)

To make the developer experience as smooth as possible, we are simplifying the onboarding process.

How? By making the Platform.sh configuration files optional (zero configuration!). Due to popular demands, we’re also giving you a simple way to control custom DNS entries directly in the YAML configuration files (see below).

Previously, if you started from one of our many ready-to-use templates, those YAML files were automatically included. But the flexibility of these files proved to be a bit overwhelming if you migrated from a different provider or simply wanted to deploy your simple & locally-built application.

That is why we decided to simplify the process and make these files optional.

Web applications may sometimes be very straightforward and not necessarily need services such as a database or a cache system like Redis. For instance, lots of static website generators (Gatsby, Jekyll, Hugo, Next.js, etc.) do not require a database and can run from a single container. Furthermore, when deploying standalone applications, one may wonder why they should bother setting up routes. 

To that end, we have simplified the required configuration for deploying applications on Platform.sh, removing the need of both services.yaml and routes.yaml when they’re not necessary.

Services configuration is now optional

If your project does not need any service, such as for a static website, you no longer need to include the .platform/services.yaml in your repository any more.

This makes things way easier for developers who are new to Platform.sh: they don't have to mingle with complex configuration files anymore.

Routes configuration is now optional 

If your project has exactly one application, it is not necessary to define a .platform/routes.yaml any more. In such cases, a default configuration will be used.

All traffic to the production domain will be sent directly to your app—auto-magically!

This ought to help out those of you with simple routing (which sends all traffic to the app) or those not familiar with the Platform.sh router concept to just build and run their apps in no time!

Support for custom hosts

We’re also introducing another fancy addition regarding configuration: the support for custom additional hosts in application containers. 

This is useful if you need to force a domain name to an IP address, like you would do in a regular /etc/hosts file.

To do this, you need to define an additional_hosts section in your .platform.app.yaml. For instance, your app container need to access a service named api.example.com with the IP address (private in this case) 192.0.2.23 add this to your .platform.app.yaml file

# .platform.app.yaml
additional_hosts:
	api.example.com: "192.0.2.23"
	web.example.com: "203.0.113.42"

In general, each entry in this section will be added to the /etc/hosts file of the application containers.

That’s all for new announcements for now! We are constantly improving the user experience of our product based on your feedback from you, our users. Please join the conversation in our forums, the Platform.sh Community where you’ll also find guides and tutorials.

And if you have any questions or need more information, please contact our support team and they’ll be sure to help.

Please stay tuned for more exciting updates in the future!