Configuration

While Lando recipes sets sane defaults so they work out of the box, they are also configurable.

Here are the configuration options, set to the default values, for this recipe's Landofile. If you are unsure about where this goes or what this means we highly recommend scanning the recipes documentation to get a good handle on how the magicks work.

recipe: platformsh
config:
  id: YOURSITEID
  overrides: {}

You will immediately notice that the default platformsh recipe Landofile does not contain much. This is because Lando uses the exact same images and configuration mechanisms locally as Platform.sh does in production.

This means that instead of modifying your Landofile to add, edit or remove the services, dependencies, build steps, etc you need to run your application you will want to modify your Platform.sh configuration according to their documentation and then do the usual lando rebuild for those changes to be applied.

Of course, since this is still a Lando recipe you can continue to extend and override your Landofile in the usual way for any additional power you require locally.

Here are some details on how Lando interprets the various Platform.sh configuration files:

routes.yaml

Lando will load your routes.yaml and use it for its own proxy configuration.

# routes.yaml

"https://{default}/":
  type: upstream
  upstream: "app:http"
  cache:
    enabled: true
    # Base the cache on the session cookie and custom Drupal cookies. Ignore all other cookies.
    cookies: ['/^SS?ESS/', '/^Drupal.visitor/']

"https://www.{default}/":
  type: redirect
  to: "https://{default}/"

The above routes configuration example will produce the following Lando pretty proxy URLs, assuming {default} resolves to my-app.lndo.site.

http://my-app.lndo.site
https://my-app.lndo.site
http://www.my-app.lndo.site
https://www.my-app.lndo.site

Note, however, that Lando will only use routes that contain the {default} placeholder. FQDN routes will not be used since these generally will be pointing at your production site and not Lando. If you would still like to use these routes then we recommend you review our proxy docs on how to add them back into the mix.

services.yaml

Lando will load your services.yaml and spin up exactly the same things there as you have running on your Platform.sh site, including any advanced configuration options you may have specified for each like schemas, endpoints, extensions, properties, etc.

This means that Lando knows how to handle more complex configuration such as in the below example:

# services.yaml

db:
  type: mariadb:10.4
  disk: 2048
  configuration:
    schemas:
      - main
      - legacy
    endpoints:
      admin:
        default_schema: main
        privileges:
          main: admin
          legacy: admin
db2:
  type: postgresql:12
  disk: 1025
  configuration:
    extensions:
      - pg_trgm
      - hstore

We currently only support the below services and we highly recommend you consult the Platform.sh docs for how to properly configure each.

• Elasticsearch
• Headless Chrome
• InfluxDB
• Kafka
• MariaDB/MySQL
• Memcached
• MongoDB
• PostgreSQL
• RabbitMQ
• Redis
• Solr
• Varnish

Also note that you will need to run a lando rebuild for configuration changes to manifest in the same way you normally would for config changes to your Landofile.

.platform.app.yaml

Lando will load your .platform.app.yaml and spin up exactly the same things there as you have running on your Platform.sh site. This means that similarly to Platform.sh Lando will also:

• Install any dependencies specificed in the build.flavor or dependencies keys
• Run any build or deploy hooks
• Set up needed relationships, variables, web config, cron tasks, etc.

We currently only support the below langauges and we highly recommend you consult the Platform.sh docs for how to properly configure each.

• PHP

Also note that you will need to run a lando rebuild for configuration changes to manifest in the same way you normally would for config changes to your Landofile.

Multiple applications

Lando should support Platform.sh's multiple applications configurations although they are not extensively tested at this point so YMMV.

If you have a multiple application setup then you will need to navigate into either the directory that contains the .platform.app.yaml or the source.root specified in your .platform/applications.yaml file to access the relevant tooling for that app.

This is how tooling works for our multiapp example.

# Get access to tooling for the "base" application
lando

# Access tooling for the "discreet" application
cd discreet
lando

# Access tooling for the "php" application
cd ../php
lando

Overriding config

Platform.sh application language and service configuration is generally optimized for production. While these values are usually also suitable for local development purposes Lando also provides a mechanism to override both application language and service configuration with values that make more sense for local.

name: myproject
recipe: platformsh
config:
  id: PROJECTID
  overrides:
    app:
      variables:
        env:
          APP_ENV: dev
        d8settings:
          skip_permissions_hardening: 1
    db:
      configuration:
        properties:
          max_allowed_packet: 63

Note that app in the above example should correspond to the name of the Platform.sh application you want to override and db should correspond to the name of one of the services in your services.yaml. Also note that you will need to lando rebuild for this changes to apply.

Environment variables

Application containers running on Lando will also set up the same PLATFORM_* provided environment variables so any service connection configuration, like connecting your Drupal site to mysql or redis, you use on Platform.sh with these variables should also automatically work on Lando.

Lando does not currently pull variables you have set up in the Platform.sh dashboard so you will need to add those manually.

Lando will also set and honor any variables that have been set up in your .platform.app.yaml or applications.yaml.

However, some of these, such as APP_ENV=prod do not make a ton of sense for local development. In these situations you can override any Platform.sh variable directly from your Landofile with values that make more sense for local. Here is an example:

name: platformsh-drupal8
recipe: platformsh
config:
  id: PROJECTID
  overrides:
    app:
      variables:
        env:
          APP_ENV: dev
        d8settings:
          skip_permissions_hardening: 1

Perhaps more importantly, Lando will not automatically pull and set up environment variables that have been set in the Platform Management Console. This means that if your build hook requires these environment variables then it will likely fail.

To remediate we recommend you manually add these variables into a local environment file that is also in your .gitignore and then lando rebuild. Here are some steps on how to do that.

1. Update your Landofile so it knows to load an environment file.

env_file:
  - platformsh.local.env

2. Make sure you add it to your .gitignore file.

platformsh.local.env

3. Create the env file

touch platformsh.local.env

4. Discover envvars by running lando platform var
5. Use the information from above to populate platformsh.local.env

SPECIAL_KEY=mysecret

6. Run lando rebuild to trigger the build process using the newly added envvars.