.lando.yml file is at the heart of every Lando app. It is needed to tell Lando what things your app needs for development. It usually will contain the services and tools needed to run and develop your app. This file should live in the root directory of your app's code repository and ideally be tracked in its version control system.
If you make changes to your
.lando.yml you will need to
lando restart your app for those changes to be applied.
The most basic
.lando.yml file contains two entries.
# The name of my application name: trivial # A list of docker compose files to load relative to my app root directory compose: - compose.yml
And can be run easily.
# Navigate to the directory with above .lando.yml cd /path/to/app # Start the app lando start
Images need to be pulled!
The first time you start an app it may need to pull down container images. This can take a moment depending on your internet connection. Subsequent pulls to that container or service are cached so they should be much faster.
You can check out the full code for this example over here. Keep reading to learn about more powerful configuration options for
If all you want to do is run a Docker Compose configuration, then the above example is for you. But Lando's real power is in its high-level abstractions with very little configuration.
Recipes offer the highest level of abstraction, composing many lower-level features of Lando into a single, top-level
name: envfile recipe: lemp
This is a working example you can run by following these instructions. It spins up a full LEMP stack out of the box.
Recipes are powerful by themselves, but recipe defaults won't always work for your application.
config option customizes specific aspects of a recipe. For example, the Drupal 8 recipe allows specifying the PHP version, the webserver, and even how to install
# Drupal 8 recipe name: d8 # Start with the default Drupal 8 recipe recipe: drupal8 # Configure the Drupal8 recipe config: # See: https://www.drupal.org/docs/7/system-requirements # Optionally specify the php version to use. # # If ommitted this will default to the latest php version supported by Drupal 8. # Consult the `php` service to see what versions are available. Note that all # such versions may not be supported in Drupal 8s so YMMV. # # See: https://www.drupal.org/docs/7/system-requirements/php # # NOTE: that this needs to be wrapped in quotes so that it is a string # php: '7.1' # Optionally specify whether you want to serve drupal via nginx or apache # # If ommitted this will default to the latest apache # # See: https://www.drupal.org/docs/7/system-requirements/web-server # via: nginx # Optionally specify the location of the webroot relative to your approot. # # If ommitted this will be your approot itself. # webroot: web # Optionally specify how you want Lando to handle Drush. There are a few options # # If omitted this will install the Drush Launcher and assume you've installed a # site-local version of Drush with Composer # # You can also configure it in the following ways: # # 1. Install via Composer # # This will install the Drush Launcher (https://github.com/drush-ops/drush-launcher) # and will delegate to the site-local version of Drush you've installed with Composer # http://docs.drush.org/en/master/install/ # drush: composer # # 2. Install Globally # # This will globally install the corresponding Drush 8 PHAR posted over at # https://github.com/drush-ops/drush/releases # drush: global:8.1.12 # # This will ATTEMPT to globally install any pre Drush 8 versions via Composer # drush: global:~7 # # 3. Specify a path # # This assumes the user has already installed Drush but wishes to tell Lando where # it exists. # drush: path:/app/vendor/bin/drush # # 4. Do nothing # # This will tell Lando to not do anything, e.g. it's up to the user # drush: false # drush: composer # Optionally specify whether you want to disable the global install of drupal console. # # You should also consider a site-local install of drupal console via composer # # See: https://hechoendrupal.gitbooks.io/drupal-console/content/en/getting/composer.html # # drupal: false # Optionally specify the database type, this can be one of: # # - `mysql` # - `mariadb` # - `postgres` # # If ommitted this will default to the latest mysql. You can additionally provide # a version with `type:version` but you will need to consult the documentation # for the correct DB service to see what versions are available # # see: https://www.drupal.org/docs/7/system-requirements/database-server # # database: mariadb:10.1 # Optionally activate xdebug # # If you are having trouble getting xdebug to work please see: # https://docs.devwithlando.io/services/php.html#using-xdebug xdebug: true # Optionally mix in your own config files # # If ommitted this will use "sane defaults" for your recipe type # conf: # For more information on setting these files check out the documentation # and examples # # Docs: https://docs.devwithlando.io/services/php.html # Examples: https://github.com/lando/lando/tree/master/examples # # server: config/drupal8.conf # php: config/php.ini # For more information on setting these files check out the documentation # and examples for the relevant services: # # MySQL: https://docs.devwithlando.io/services/mysql.html # MariaDB: https://docs.devwithlando.io/services/mariadb.html # PostGres: https://docs.devwithlando.io/services/postgres.html # # Examples: https://github.com/lando/lando/tree/master/examples # # database: config/mysql
config block, some recipes allow mounting custom language- or service-specific config files via the
config: conf: php: ./path/to/host/config/dir/php.ini
These can include:
- .ini files for PHP
- .conf files for Apache/Nginx
- config directories for MySQL/MariaDB/PostGres
Recipes are simply common development use-cases, composed of different combinations of
events. Each of these is a first-class citizens in Lando, with its own top-level configuration options. They can run alongside recipes or raw
compose setups to extend functionality.
services block describes any number of single services, such as
mysql. It always expects a
type to specified. Other supported options within a service block depend on the type.
name: myapp recipe: lamp # Let's add a Redis cache service that our PHP service can talk to services: cache: type: redis
Read more about services.
tooling block can define arbitrary
lando commands, which map to arbitrary commands that run inside specific service containers. The key for each block becomes the name of the
lando sub-command. For example, say you want to expose a CLI into your Redis service above. Just add this:
tooling: redis-cli: service: cache
Lando interprets this as "add a
lando redis-cli subcommand that executes
redis-cli inside the container running the
Read more about tooling.
proxy block defines custom domains for your services. Lando does this automatically, but by adding a
proxy config you can map additional domains on your host machine to arbitrary services. To add a domain for a service called
myapp, for example, simply add a
myapp block with one or more domain names, defined as a YAML array:
proxy: myapp: - custom-name.lndo.site - another-name.lndo.site
This comes with several caveats, so be sure to read the Proxy docs to understand the limitations.
Lando apps expose a powerful event-based API. By defining a top-level
events block, you can run arbitrary commands before or after any supported event.
The syntax is simple:
post-eventname blocks tell Lando to run extra commands before and after
eventname fires, respectively. Individual event blocks are declared as YAML arrays. Within each array, the syntax for a single command tells Lando which to service to run it in. This means that one
pre- event block can declare any number of commands to be run in separate services:
services: tweeter: type: node # Tell lando what to do after we run `lando autotweet` events: post-autotweet - appserver: /path/to/tweeter-scraper.sh --with options - echo 'tweeter service is tweeting' tooling: autotweet: service: tweeter cmd: "node autotweet.js --all-caps"
Lando determines which service to run the command in according to the following rules:
- If the command is defined in the form
SERVICENAMEis a service declared in the
servicesblock, the command is executed in that service.
- If the event name is a tooling command, the command is executed in the
servicedeclared in the tooling command block.
- If neither condition is met, Lando runs the command in
In the above example,
lando autotweet covfefe results in the following, in this order:
node autotweet.js --all-caps covfefeis run inside the
tweeterservice (as a normal tooling command)
/path/to/tweeter-scraper.sh --with optionsis run inside
appserver(because it was declared with the
echo 'tweeter service is tweeting'is run inside the
autotweetis a tooling command for the
Read more about events