---
layout: docs
page_title: Vagrant Triggers
description: Introduction to Vagrant Triggers
---

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

```ruby
# 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.

```ruby
# 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:

```ruby
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:

```ruby
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
```

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](/docs/triggers/configuration).
