June 20-22 Announcing HashiConf Europe full schedule: keynotes, sessions, labs & more Register Now
  • Infrastructure
    • terraform
    • packer
  • Networking
    • consul
  • Security
    • vault
    • boundary
  • Applications
    • nomad
    • waypoint
    • vagrant
  • HashiCorp Cloud Platform

    A fully managed platform to automate infrastructure on any cloud with HashiCorp products.

    • consul
    • terraform
    • vault
    • packerbeta
    Visit cloud.hashicorp.com
  • Intro
  • Docs
  • Community
GitHub—Stars on GitHub
Download
    • v2.2.19 (latest)
    • v2.2.18
    • v2.2.17
    • v2.2.16
    • v2.2.15
    • v2.2.14
    • v2.2.13
    • v2.2.12
    • v2.2.11
    • v2.2.10
  • Overview
    • Overview
    • Backwards Compatibility
    • Upgrading
    • Upgrading from 1.0.x
    • From Source
    • Uninstallation
    • Overview
    • box
    • cloud
    • connect
    • destroy
    • global-status
    • halt
    • init
    • login
    • package
    • plugin
    • port
    • powershell
    • provision
    • rdp
    • reload
    • resume
    • share
    • snapshot
    • ssh
    • ssh-config
    • status
    • suspend
    • up
    • upload
    • validate
    • version
    • More Commands
    • Aliases
    • Machine Readable Output
    • rsync
    • rsync-auto
    • winrm
    • winrm_config
    • Overview
    • HTTP Sharing
    • SSH Sharing
    • Connect
    • Security
    • Custom Provider
    • Overview
    • Configuration Version
    • Minimum Vagrant Version
    • Tips & Tricks
    • config.vm
    • config.ssh
    • config.winrm
    • config.winssh
    • config.vagrant
    • Overview
    • Box Versioning
    • Creating a Base Box
    • Box File Format
    • Box Info Format
    • Overview
    • Basic Usage
    • File
    • Shell
    • Ansible Intro
    • Ansible
    • Ansible Local
    • Common Ansible Options
    • CFEngine
    • Chef Common Configuration
    • Chef Solo
    • Chef Zero
    • Chef Client
    • Chef Apply
    • Docker
    • Podman
    • Puppet Apply
    • Puppet Agent
    • Salt
    • Overview
    • Basic Usage
    • Forwarded Ports
    • Private Network
    • Public Network
    • Overview
    • Basic Usage
    • NFS
    • RSync
    • SMB
    • VirtualBox
    • Overview
    • Configuration
    • Usage
    • Overview
    • Configuration
    • Usage
      • Overview
      • Usage
      • Common Issues
      • Overview
      • Usage
      • Common Issues
      • Overview
      • Usage
      • Common Issues
  • Multi-Machine
    • Overview
    • Installation
    • Basic Usage
    • Configuration
    • Default Provider
      • Overview
      • Usage
      • Creating a Base Box
      • Configuration
      • Networking
      • Common Issues
      • Overview
      • Installation
      • VMware Utility
      • Usage
      • Boxes
      • Configuration
      • Known Issues
      • FAQ
      • Overview
      • Basic Usage
      • Commands
      • Boxes
      • Configuration
      • Networking
      • Overview
      • Usage
      • Creating a Base Box
      • Configuration
      • Limitations
    • Custom Provider
    • Overview
    • Usage
    • Plugin Development Basics
    • Action Hooks
    • Commands
    • Configuration
    • Guests
    • Guest Capabilities
    • Hosts
    • Host Capabilities
    • Providers
    • Provisioners
    • Packaging & Distribution
    • Overview
    • FTP / SFTP
    • Heroku
    • Local Exec
    • Overview
    • Configuration
    • Usage
  • Experimental
    • Overview
    • Debugging
    • Environmental Variables
    • WSL
    • macOS Catalina

  • Vagrant Cloud
Type '/' to Search

»Vagrant Triggers

As of version 2.1.0, Vagrant is capable of executing machine triggers before or after Vagrant commands.

Each trigger is expected to be given a command key for when it should be fired during the Vagrant command lifecycle. These could be defined as a single key or an array which acts like a whitelist for the defined trigger.

# single command trigger
config.trigger.after :up do |trigger|
...
end

# multiple commands for this trigger
config.trigger.before [:up, :destroy, :halt, :package] do |trigger|
...
end

# or defined as a splat list
config.trigger.before :up, :destroy, :halt, :package do |trigger|
...
end
# single command trigger
config.trigger.after :up do |trigger|
...
end

# multiple commands for this trigger
config.trigger.before [:up, :destroy, :halt, :package] do |trigger|
...
end

# or defined as a splat list
config.trigger.before :up, :destroy, :halt, :package do |trigger|
...
end

Alternatively, the key :all could be given which would run the trigger before or after every Vagrant command. If there is a command you don't want the trigger to run on, you can ignore that command with the ignore option.

# single command trigger
config.trigger.before :all do |trigger|
  trigger.info = "Running a before trigger!"
  trigger.ignore = [:destroy, :halt]
end
# single command trigger
config.trigger.before :all do |trigger|
  trigger.info = "Running a before trigger!"
  trigger.ignore = [:destroy, :halt]
end

Note: If a trigger is defined on a command that does not exist, a warning will be displayed.

Triggers can be defined as a block or hash in a Vagrantfile. The example below will result in the same trigger:

config.trigger.after :up do |trigger|
  trigger.name = "Finished Message"
  trigger.info = "Machine is up!"
end

config.trigger.after :up,
  name: "Finished Message",
  info: "Machine is up!"
config.trigger.after :up do |trigger|
  trigger.name = "Finished Message"
  trigger.info = "Machine is up!"
end

config.trigger.after :up,
  name: "Finished Message",
  info: "Machine is up!"

Triggers can also be defined within the scope of guests in a Vagrantfile. These triggers will only run on the configured guest. An example of a guest only trigger:

config.vm.define "ubuntu" do |ubuntu|
  ubuntu.vm.box = "ubuntu"
  ubuntu.trigger.before :destroy do |trigger|
    trigger.warn = "Dumping database to /vagrant/outfile"
    trigger.run_remote = {inline: "pg_dump dbname > /vagrant/outfile"}
  end
end
config.vm.define "ubuntu" do |ubuntu|
  ubuntu.vm.box = "ubuntu"
  ubuntu.trigger.before :destroy do |trigger|
    trigger.warn = "Dumping database to /vagrant/outfile"
    trigger.run_remote = {inline: "pg_dump dbname > /vagrant/outfile"}
  end
end

Global and machine-scoped triggers will execute in the order that they are defined within a Vagrantfile. Take for example an abstracted Vagrantfile:

Vagrantfile
  global trigger 1
  global trigger 2
  machine defined
    machine trigger 3
  global trigger 4
end
Vagrantfile
  global trigger 1
  global trigger 2
  machine defined
    machine trigger 3
  global trigger 4
end

In this generic case, the triggers would fire in the order: 1 -> 2 -> 3 -> 4

For more information about what options are available for triggers, see the configuration section.

github logoEdit this page
IntroDocsBookVMwarePrivacySecurityPress KitConsent Manager