diff --git a/website/.buildpacks b/website/.buildpacks
new file mode 100644
index 000000000..f85b304c3
--- /dev/null
+++ b/website/.buildpacks
@@ -0,0 +1,2 @@
+https://github.com/heroku/heroku-buildpack-ruby.git
+https://github.com/hashicorp/heroku-buildpack-middleman.git
diff --git a/website/Gemfile b/website/Gemfile
new file mode 100644
index 000000000..7ef6a8f31
--- /dev/null
+++ b/website/Gemfile
@@ -0,0 +1,3 @@
+source "https://rubygems.org"
+
+gem "middleman-hashicorp", github: "hashicorp/middleman-hashicorp"
diff --git a/website/Gemfile.lock b/website/Gemfile.lock
new file mode 100644
index 000000000..216114847
--- /dev/null
+++ b/website/Gemfile.lock
@@ -0,0 +1,182 @@
+GIT
+  remote: git://github.com/hashicorp/middleman-hashicorp.git
+  revision: 76f0f284ad44cea0457484ea83467192f02daf87
+  specs:
+    middleman-hashicorp (0.1.0)
+      bootstrap-sass (~> 3.3)
+      builder (~> 3.2)
+      less (~> 2.6)
+      middleman (~> 3.3)
+      middleman-livereload (~> 3.4)
+      middleman-minify-html (~> 3.4)
+      middleman-syntax (~> 2.0)
+      rack-contrib (~> 1.2)
+      rack-protection (~> 1.5)
+      rack-rewrite (~> 1.5)
+      rack-ssl-enforcer (~> 0.2)
+      redcarpet (~> 3.2)
+      therubyracer (~> 0.12)
+      thin (~> 1.6)
+
+GEM
+  remote: https://rubygems.org/
+  specs:
+    activesupport (4.1.12)
+      i18n (~> 0.6, >= 0.6.9)
+      json (~> 1.7, >= 1.7.7)
+      minitest (~> 5.1)
+      thread_safe (~> 0.1)
+      tzinfo (~> 1.1)
+    autoprefixer-rails (5.2.1)
+      execjs
+      json
+    bootstrap-sass (3.3.5.1)
+      autoprefixer-rails (>= 5.0.0.1)
+      sass (>= 3.3.0)
+    builder (3.2.2)
+    celluloid (0.16.0)
+      timers (~> 4.0.0)
+    chunky_png (1.3.4)
+    coffee-script (2.4.1)
+      coffee-script-source
+      execjs
+    coffee-script-source (1.9.1.1)
+    commonjs (0.2.7)
+    compass (1.0.3)
+      chunky_png (~> 1.2)
+      compass-core (~> 1.0.2)
+      compass-import-once (~> 1.0.5)
+      rb-fsevent (>= 0.9.3)
+      rb-inotify (>= 0.9)
+      sass (>= 3.3.13, < 3.5)
+    compass-core (1.0.3)
+      multi_json (~> 1.0)
+      sass (>= 3.3.0, < 3.5)
+    compass-import-once (1.0.5)
+      sass (>= 3.2, < 3.5)
+    daemons (1.2.3)
+    em-websocket (0.5.1)
+      eventmachine (>= 0.12.9)
+      http_parser.rb (~> 0.6.0)
+    erubis (2.7.0)
+    eventmachine (1.0.7)
+    execjs (2.5.2)
+    ffi (1.9.10)
+    git-version-bump (0.15.1)
+    haml (4.0.6)
+      tilt
+    hike (1.2.3)
+    hitimes (1.2.2)
+    hooks (0.4.0)
+      uber (~> 0.0.4)
+    htmlcompressor (0.2.0)
+    http_parser.rb (0.6.0)
+    i18n (0.7.0)
+    json (1.8.3)
+    kramdown (1.8.0)
+    less (2.6.0)
+      commonjs (~> 0.2.7)
+    libv8 (3.16.14.11)
+    listen (2.10.1)
+      celluloid (~> 0.16.0)
+      rb-fsevent (>= 0.9.3)
+      rb-inotify (>= 0.9)
+    middleman (3.3.12)
+      coffee-script (~> 2.2)
+      compass (>= 1.0.0, < 2.0.0)
+      compass-import-once (= 1.0.5)
+      execjs (~> 2.0)
+      haml (>= 4.0.5)
+      kramdown (~> 1.2)
+      middleman-core (= 3.3.12)
+      middleman-sprockets (>= 3.1.2)
+      sass (>= 3.4.0, < 4.0)
+      uglifier (~> 2.5)
+    middleman-core (3.3.12)
+      activesupport (~> 4.1.0)
+      bundler (~> 1.1)
+      erubis
+      hooks (~> 0.3)
+      i18n (~> 0.7.0)
+      listen (>= 2.7.9, < 3.0)
+      padrino-helpers (~> 0.12.3)
+      rack (>= 1.4.5, < 2.0)
+      rack-test (~> 0.6.2)
+      thor (>= 0.15.2, < 2.0)
+      tilt (~> 1.4.1, < 2.0)
+    middleman-livereload (3.4.2)
+      em-websocket (~> 0.5.1)
+      middleman-core (>= 3.3)
+      rack-livereload (~> 0.3.15)
+    middleman-minify-html (3.4.1)
+      htmlcompressor (~> 0.2.0)
+      middleman-core (>= 3.2)
+    middleman-sprockets (3.4.2)
+      middleman-core (>= 3.3)
+      sprockets (~> 2.12.1)
+      sprockets-helpers (~> 1.1.0)
+      sprockets-sass (~> 1.3.0)
+    middleman-syntax (2.0.0)
+      middleman-core (~> 3.2)
+      rouge (~> 1.0)
+    minitest (5.7.0)
+    multi_json (1.11.2)
+    padrino-helpers (0.12.5)
+      i18n (~> 0.6, >= 0.6.7)
+      padrino-support (= 0.12.5)
+      tilt (~> 1.4.1)
+    padrino-support (0.12.5)
+      activesupport (>= 3.1)
+    rack (1.6.4)
+    rack-contrib (1.3.0)
+      git-version-bump (~> 0.15)
+      rack (~> 1.4)
+    rack-livereload (0.3.16)
+      rack
+    rack-protection (1.5.3)
+      rack
+    rack-rewrite (1.5.1)
+    rack-ssl-enforcer (0.2.8)
+    rack-test (0.6.3)
+      rack (>= 1.0)
+    rb-fsevent (0.9.5)
+    rb-inotify (0.9.5)
+      ffi (>= 0.5.0)
+    redcarpet (3.3.2)
+    ref (2.0.0)
+    rouge (1.9.1)
+    sass (3.4.16)
+    sprockets (2.12.4)
+      hike (~> 1.2)
+      multi_json (~> 1.0)
+      rack (~> 1.0)
+      tilt (~> 1.1, != 1.3.0)
+    sprockets-helpers (1.1.0)
+      sprockets (~> 2.0)
+    sprockets-sass (1.3.1)
+      sprockets (~> 2.0)
+      tilt (~> 1.1)
+    therubyracer (0.12.2)
+      libv8 (~> 3.16.14.0)
+      ref
+    thin (1.6.3)
+      daemons (~> 1.0, >= 1.0.9)
+      eventmachine (~> 1.0)
+      rack (~> 1.0)
+    thor (0.19.1)
+    thread_safe (0.3.5)
+    tilt (1.4.1)
+    timers (4.0.1)
+      hitimes
+    tzinfo (1.2.2)
+      thread_safe (~> 0.1)
+    uber (0.0.13)
+    uglifier (2.7.1)
+      execjs (>= 0.3.0)
+      json (>= 1.8.0)
+
+PLATFORMS
+  ruby
+
+DEPENDENCIES
+  middleman-hashicorp!
diff --git a/website/LICENSE.md b/website/LICENSE.md
new file mode 100644
index 000000000..f8bf349a8
--- /dev/null
+++ b/website/LICENSE.md
@@ -0,0 +1,10 @@
+# Proprietary License
+
+This license is temporary while a more official one is drafted. However,
+this should make it clear:
+
+* The text contents of this website are MPL 2.0 licensed.
+
+* The design contents of this website are proprietary and may not be reproduced
+  or reused in any way other than to run the Vault website locally. The license
+  for the design is owned solely by HashiCorp, Inc.
diff --git a/website/Procfile b/website/Procfile
new file mode 100644
index 000000000..58361e473
--- /dev/null
+++ b/website/Procfile
@@ -0,0 +1 @@
+web: bundle exec thin start -p $PORT
diff --git a/website/README.md b/website/README.md
new file mode 100644
index 000000000..fb6d2719c
--- /dev/null
+++ b/website/README.md
@@ -0,0 +1,24 @@
+# Nomad Website
+
+This subdirectory contains the entire source for the [Nomad Website](https://nomadproject.io/).
+This is a [Middleman](http://middlemanapp.com) project, which builds a static
+site from these source files.
+
+## Contributions Welcome!
+
+If you find a typo or you feel like you can improve the HTML, CSS, or
+JavaScript, we welcome contributions. Feel free to open issues or pull
+requests like any normal GitHub project, and we'll merge it in.
+
+## Running the Site Locally
+
+Running the site locally is simple. Clone this repo and run the following
+commands:
+
+```
+$ bundle
+$ bundle exec middleman server
+```
+
+Then open up `http://localhost:4567`. Note that some URLs you may need to append
+".html" to make them work (in the navigation).
diff --git a/website/Vagrantfile b/website/Vagrantfile
new file mode 100644
index 000000000..d360738a7
--- /dev/null
+++ b/website/Vagrantfile
@@ -0,0 +1,38 @@
+# -*- mode: ruby -*-
+# vi: set ft=ruby :
+
+# Vagrantfile API/syntax version. Don't touch unless you know what you're doing!
+VAGRANTFILE_API_VERSION = "2"
+
+$script = <<SCRIPT
+sudo apt-get -y update
+
+# RVM/Ruby
+sudo apt-get -y install curl
+curl -sSL https://get.rvm.io | bash -s stable
+. ~/.bashrc
+. ~/.bash_profile
+rvm install 2.0.0
+rvm --default use 2.0.0
+
+# Middleman deps
+cd /vagrant
+bundle
+
+# JS stuff
+sudo apt-get install -y python-software-properties
+sudo add-apt-repository -y ppa:chris-lea/node.js
+sudo apt-get update -y
+sudo apt-get install -y nodejs
+
+# Get JS deps
+cd /vagrant/source
+npm install
+SCRIPT
+
+Vagrant.configure(VAGRANTFILE_API_VERSION) do |config|
+  config.vm.box = "chef/ubuntu-12.04"
+  config.vm.network "private_network", ip: "33.33.30.10"
+  config.vm.provision "shell", inline: $script, privileged: false
+  config.vm.synced_folder ".", "/vagrant", type: "rsync"
+end
diff --git a/website/config.rb b/website/config.rb
new file mode 100644
index 000000000..0c7f7bdb2
--- /dev/null
+++ b/website/config.rb
@@ -0,0 +1,15 @@
+#-------------------------------------------------------------------------
+# Configure Middleman
+#-------------------------------------------------------------------------
+
+set :base_url, "https://www.vaultproject.io/"
+
+activate :hashicorp do |h|
+  h.version         = ENV["VAULT_VERSION"]
+  h.bintray_enabled = ENV["BINTRAY_ENABLED"]
+  h.bintray_repo    = "mitchellh/vault"
+  h.bintray_user    = "mitchellh"
+  h.bintray_key     = ENV["BINTRAY_API_KEY"]
+
+  h.minify_javascript = false
+end
diff --git a/website/config.ru b/website/config.ru
new file mode 100644
index 000000000..2edfd312e
--- /dev/null
+++ b/website/config.ru
@@ -0,0 +1,38 @@
+require "rack"
+require "rack/contrib/not_found"
+require "rack/contrib/response_headers"
+require "rack/contrib/static_cache"
+require "rack/contrib/try_static"
+require "rack/protection"
+
+# Protect against various bad things
+use Rack::Protection::JsonCsrf
+use Rack::Protection::RemoteReferrer
+use Rack::Protection::HttpOrigin
+use Rack::Protection::EscapedParams
+use Rack::Protection::XSSHeader
+use Rack::Protection::FrameOptions
+use Rack::Protection::PathTraversal
+use Rack::Protection::IPSpoofing
+
+# Properly compress the output if the client can handle it.
+use Rack::Deflater
+
+# Set the "forever expire" cache headers for these static assets. Since
+# we hash the contents of the assets to determine filenames, this is safe
+# to do.
+use Rack::StaticCache,
+  :root => "build",
+  :urls => ["/images", "/javascripts", "/stylesheets", "/webfonts"],
+  :duration => 2,
+  :versioning => false
+
+# Try to find a static file that matches our request, since Middleman
+# statically generates everything.
+use Rack::TryStatic,
+  :root => "build",
+  :urls => ["/"],
+  :try  => [".html", "index.html", "/index.html"]
+
+# 404 if we reached this point. Sad times.
+run Rack::NotFound.new(File.expand_path("../build/404.html", __FILE__))
diff --git a/website/helpers/sidebar_helpers.rb b/website/helpers/sidebar_helpers.rb
new file mode 100644
index 000000000..124a7c53c
--- /dev/null
+++ b/website/helpers/sidebar_helpers.rb
@@ -0,0 +1,12 @@
+module SidebarHelpers
+  # This helps by setting the "active" class for sidebar nav elements
+  # if the YAML frontmatter matches the expected value.
+  def sidebar_current(expected)
+    current = current_page.data.sidebar_current || ""
+    if current.start_with?(expected)
+      return " class=\"active\""
+    else
+      return ""
+    end
+  end
+end
diff --git a/website/source/.gitignore b/website/source/.gitignore
new file mode 100644
index 000000000..67550a149
--- /dev/null
+++ b/website/source/.gitignore
@@ -0,0 +1,2 @@
+# Source folder
+node_modules/
diff --git a/website/source/404.html.erb b/website/source/404.html.erb
new file mode 100644
index 000000000..e7dcdc5a2
--- /dev/null
+++ b/website/source/404.html.erb
@@ -0,0 +1,5 @@
+---
+noindex: true
+---
+
+<h2>Page Not Found</h2>
diff --git a/website/source/assets/images/caret-green.png b/website/source/assets/images/caret-green.png
new file mode 100644
index 000000000..91aef2aff
Binary files /dev/null and b/website/source/assets/images/caret-green.png differ
diff --git a/website/source/assets/images/caret-green@2x.png b/website/source/assets/images/caret-green@2x.png
new file mode 100644
index 000000000..cdd8d7222
Binary files /dev/null and b/website/source/assets/images/caret-green@2x.png differ
diff --git a/website/source/assets/images/caret-light.png b/website/source/assets/images/caret-light.png
new file mode 100644
index 000000000..639359f04
Binary files /dev/null and b/website/source/assets/images/caret-light.png differ
diff --git a/website/source/assets/images/caret-light@2x.png b/website/source/assets/images/caret-light@2x.png
new file mode 100644
index 000000000..499e57d3c
Binary files /dev/null and b/website/source/assets/images/caret-light@2x.png differ
diff --git a/website/source/assets/images/caret-white.png b/website/source/assets/images/caret-white.png
new file mode 100644
index 000000000..546712f18
Binary files /dev/null and b/website/source/assets/images/caret-white.png differ
diff --git a/website/source/assets/images/caret-white@2x.png b/website/source/assets/images/caret-white@2x.png
new file mode 100644
index 000000000..6b23a6d34
Binary files /dev/null and b/website/source/assets/images/caret-white@2x.png differ
diff --git a/website/source/assets/images/favicon.png b/website/source/assets/images/favicon.png
new file mode 100644
index 000000000..6ca6ef2d0
Binary files /dev/null and b/website/source/assets/images/favicon.png differ
diff --git a/website/source/assets/images/favicon@2x.png b/website/source/assets/images/favicon@2x.png
new file mode 100644
index 000000000..130634732
Binary files /dev/null and b/website/source/assets/images/favicon@2x.png differ
diff --git a/website/source/assets/images/feature-density.png b/website/source/assets/images/feature-density.png
new file mode 100644
index 000000000..f5bf8f667
Binary files /dev/null and b/website/source/assets/images/feature-density.png differ
diff --git a/website/source/assets/images/feature-density@2x.png b/website/source/assets/images/feature-density@2x.png
new file mode 100644
index 000000000..ce195fe91
Binary files /dev/null and b/website/source/assets/images/feature-density@2x.png differ
diff --git a/website/source/assets/images/feature-deploy.png b/website/source/assets/images/feature-deploy.png
new file mode 100644
index 000000000..f9e393283
Binary files /dev/null and b/website/source/assets/images/feature-deploy.png differ
diff --git a/website/source/assets/images/feature-deploy@2x.png b/website/source/assets/images/feature-deploy@2x.png
new file mode 100644
index 000000000..62a82c2c5
Binary files /dev/null and b/website/source/assets/images/feature-deploy@2x.png differ
diff --git a/website/source/assets/images/feature-healing.png b/website/source/assets/images/feature-healing.png
new file mode 100644
index 000000000..3643533f4
Binary files /dev/null and b/website/source/assets/images/feature-healing.png differ
diff --git a/website/source/assets/images/feature-healing@2x.png b/website/source/assets/images/feature-healing@2x.png
new file mode 100644
index 000000000..aaa8a3af3
Binary files /dev/null and b/website/source/assets/images/feature-healing@2x.png differ
diff --git a/website/source/assets/images/feature-manage.png b/website/source/assets/images/feature-manage.png
new file mode 100644
index 000000000..9b820d2a9
Binary files /dev/null and b/website/source/assets/images/feature-manage.png differ
diff --git a/website/source/assets/images/feature-manage@2x.png b/website/source/assets/images/feature-manage@2x.png
new file mode 100644
index 000000000..43184e13c
Binary files /dev/null and b/website/source/assets/images/feature-manage@2x.png differ
diff --git a/website/source/assets/images/hashi-logo.png b/website/source/assets/images/hashi-logo.png
new file mode 100644
index 000000000..1f896c0c6
Binary files /dev/null and b/website/source/assets/images/hashi-logo.png differ
diff --git a/website/source/assets/images/hashi-logo@2x.png b/website/source/assets/images/hashi-logo@2x.png
new file mode 100644
index 000000000..84ad6b9bd
Binary files /dev/null and b/website/source/assets/images/hashi-logo@2x.png differ
diff --git a/website/source/assets/images/hero-image.png b/website/source/assets/images/hero-image.png
new file mode 100644
index 000000000..42df0b99c
Binary files /dev/null and b/website/source/assets/images/hero-image.png differ
diff --git a/website/source/assets/images/hero-image@2x.png b/website/source/assets/images/hero-image@2x.png
new file mode 100644
index 000000000..532049c03
Binary files /dev/null and b/website/source/assets/images/hero-image@2x.png differ
diff --git a/website/source/assets/images/hero-logotype.png b/website/source/assets/images/hero-logotype.png
new file mode 100644
index 000000000..6ec09f8bd
Binary files /dev/null and b/website/source/assets/images/hero-logotype.png differ
diff --git a/website/source/assets/images/hero-logotype@2x.png b/website/source/assets/images/hero-logotype@2x.png
new file mode 100644
index 000000000..e82432bce
Binary files /dev/null and b/website/source/assets/images/hero-logotype@2x.png differ
diff --git a/website/source/assets/images/icon-docker-outline.png b/website/source/assets/images/icon-docker-outline.png
new file mode 100644
index 000000000..0719d7b45
Binary files /dev/null and b/website/source/assets/images/icon-docker-outline.png differ
diff --git a/website/source/assets/images/icon-docker-outline@2x.png b/website/source/assets/images/icon-docker-outline@2x.png
new file mode 100644
index 000000000..214ad45d0
Binary files /dev/null and b/website/source/assets/images/icon-docker-outline@2x.png differ
diff --git a/website/source/assets/images/icon-download.png b/website/source/assets/images/icon-download.png
new file mode 100644
index 000000000..e625bf603
Binary files /dev/null and b/website/source/assets/images/icon-download.png differ
diff --git a/website/source/assets/images/icon-download@2x.png b/website/source/assets/images/icon-download@2x.png
new file mode 100644
index 000000000..01582b68a
Binary files /dev/null and b/website/source/assets/images/icon-download@2x.png differ
diff --git a/website/source/assets/images/icon-github.png b/website/source/assets/images/icon-github.png
new file mode 100644
index 000000000..463bb61b8
Binary files /dev/null and b/website/source/assets/images/icon-github.png differ
diff --git a/website/source/assets/images/icon-github@2x.png b/website/source/assets/images/icon-github@2x.png
new file mode 100644
index 000000000..ec10c210c
Binary files /dev/null and b/website/source/assets/images/icon-github@2x.png differ
diff --git a/website/source/assets/images/logo-header.png b/website/source/assets/images/logo-header.png
new file mode 100644
index 000000000..ebe394a76
Binary files /dev/null and b/website/source/assets/images/logo-header.png differ
diff --git a/website/source/assets/images/logo-header@2x.png b/website/source/assets/images/logo-header@2x.png
new file mode 100644
index 000000000..0419591c2
Binary files /dev/null and b/website/source/assets/images/logo-header@2x.png differ
diff --git a/website/source/assets/images/partner-amazon.png b/website/source/assets/images/partner-amazon.png
new file mode 100644
index 000000000..302ee59b7
Binary files /dev/null and b/website/source/assets/images/partner-amazon.png differ
diff --git a/website/source/assets/images/partner-amazon@2x.png b/website/source/assets/images/partner-amazon@2x.png
new file mode 100644
index 000000000..be137c8cf
Binary files /dev/null and b/website/source/assets/images/partner-amazon@2x.png differ
diff --git a/website/source/assets/images/partner-docker.png b/website/source/assets/images/partner-docker.png
new file mode 100644
index 000000000..e8136ca47
Binary files /dev/null and b/website/source/assets/images/partner-docker.png differ
diff --git a/website/source/assets/images/partner-docker@2x.png b/website/source/assets/images/partner-docker@2x.png
new file mode 100644
index 000000000..25a3384a6
Binary files /dev/null and b/website/source/assets/images/partner-docker@2x.png differ
diff --git a/website/source/assets/images/partner-engineyard.png b/website/source/assets/images/partner-engineyard.png
new file mode 100644
index 000000000..c8391ea25
Binary files /dev/null and b/website/source/assets/images/partner-engineyard.png differ
diff --git a/website/source/assets/images/partner-engineyard@2x.png b/website/source/assets/images/partner-engineyard@2x.png
new file mode 100644
index 000000000..98d3f0c9b
Binary files /dev/null and b/website/source/assets/images/partner-engineyard@2x.png differ
diff --git a/website/source/assets/images/partner-google.png b/website/source/assets/images/partner-google.png
new file mode 100644
index 000000000..4164ce617
Binary files /dev/null and b/website/source/assets/images/partner-google.png differ
diff --git a/website/source/assets/images/partner-google@2x.png b/website/source/assets/images/partner-google@2x.png
new file mode 100644
index 000000000..fbac4df82
Binary files /dev/null and b/website/source/assets/images/partner-google@2x.png differ
diff --git a/website/source/assets/images/partner-microsoft.png b/website/source/assets/images/partner-microsoft.png
new file mode 100644
index 000000000..b59099617
Binary files /dev/null and b/website/source/assets/images/partner-microsoft.png differ
diff --git a/website/source/assets/images/partner-microsoft@2x.png b/website/source/assets/images/partner-microsoft@2x.png
new file mode 100644
index 000000000..04d13bb0b
Binary files /dev/null and b/website/source/assets/images/partner-microsoft@2x.png differ
diff --git a/website/source/assets/images/triangle-sprite.png b/website/source/assets/images/triangle-sprite.png
new file mode 100644
index 000000000..1fce9c055
Binary files /dev/null and b/website/source/assets/images/triangle-sprite.png differ
diff --git a/website/source/assets/images/triangle-sprite@2x.png b/website/source/assets/images/triangle-sprite@2x.png
new file mode 100644
index 000000000..2527a62e0
Binary files /dev/null and b/website/source/assets/images/triangle-sprite@2x.png differ
diff --git a/website/source/assets/javascripts/app/CubeDraw.js b/website/source/assets/javascripts/app/CubeDraw.js
new file mode 100644
index 000000000..72a24c202
--- /dev/null
+++ b/website/source/assets/javascripts/app/CubeDraw.js
@@ -0,0 +1,82 @@
+(function(){
+
+CubeDraw = Base.extend({
+
+	$cube: null,
+	ROWS: 4,
+	PADDING: 64, // 44 pixel base square + 20 padding
+	previousRowTop: null,
+	previousRowLeft: null,
+	lastCube: null,
+
+	constructor: function(){
+		this.$cube = $('.cube');
+		this.$cubes = $('#cubes');
+
+		this.lastCube = this.$cube;
+		this.previousRowLeft = parseInt(this.lastCube.css('left'), 10)
+		this.previousRowTop = parseInt(this.lastCube.css('top'), 10);
+
+		this.addEventListeners();
+	},
+
+	addEventListeners: function(){
+		var angle = this.getRadiansForAngle(30);
+		var sin = Math.sin(angle) * this.PADDING;
+		var cos = Math.cos(angle) * this.PADDING;
+
+		//sett up our parent columns
+		for(var i = 0; i < this.ROWS; i++){
+			var cube = this.lastCube.clone();
+
+			cube.css({ top: this.previousRowTop - sin, left: this.previousRowLeft - cos});
+			this.$cubes.prepend(cube);
+			this.lastCube = cube;
+			this.previousRowLeft = parseInt(this.lastCube.css('left'), 10)
+			this.previousRowTop = parseInt(this.lastCube.css('top'), 10)
+		}
+
+		//use the parent cubes as starting point for rows
+		var $allParentCubes = $('.cube');
+		var angle = this.getRadiansForAngle(150);
+		var sin = Math.sin(angle) * this.PADDING;
+		var cos = Math.cos(angle) * this.PADDING;
+
+		for(var j = this.ROWS; j > -1 ; j--){
+			var baseCube = $($allParentCubes[j]);
+
+			this.previousRowLeft = parseInt(baseCube.css('left'), 10)
+			this.previousRowTop = parseInt(baseCube.css('top'), 10)
+
+			for(var n = 0; n < this.ROWS; n++){
+				var cube = baseCube.clone();
+				cube.css({ top: this.previousRowTop - sin, left: this.previousRowLeft - cos});
+
+				this.$cubes.prepend(cube);
+
+				this.lastCube = cube;
+				this.previousRowLeft = parseInt(this.lastCube.css('left'), 10)
+				this.previousRowTop = parseInt(this.lastCube.css('top'), 10)
+			}
+		}
+
+		var $all = $('.cube');
+		for(var c = 0; c < $all.length; c++){
+			(function(index){
+				setTimeout(function(){
+					var $theCube = $($all[index]);
+					$theCube.addClass('in')
+				}, 100*c)
+			})(c)
+		}
+	},
+
+	getRadiansForAngle: function(angle) {
+		return angle * (Math.PI/180);
+	}
+
+});
+
+window.CubeDraw = CubeDraw;
+
+})();
diff --git a/website/source/assets/javascripts/app/DotLockup.js b/website/source/assets/javascripts/app/DotLockup.js
new file mode 100644
index 000000000..8eae2ca58
--- /dev/null
+++ b/website/source/assets/javascripts/app/DotLockup.js
@@ -0,0 +1,130 @@
+(function(){
+
+DotLockup = Base.extend({
+
+	$keyWrap: null,
+	$keys: null,
+
+	constructor: function(){
+		var _this = this;
+
+		_this.$keyWrap = $('.keys');
+		_this.$keys = $('.keys span');
+
+		//(3000)
+
+		_this.addEventListeners();
+		_this.animateFull()
+			.then(_this.animateOff.bind(this))
+			.then(_this.animateFull.bind(this))
+			.then(_this.animatePress.bind(this))
+			.then(_this.resetKeys.bind(this));
+	},
+
+	addEventListeners: function(){
+		var _this = this;
+	},
+
+	animateFull: function(uberDelay){
+		var _this = this,
+			uberDelay = uberDelay || 0,
+			deferred = $.Deferred();
+
+		setTimeout( function(){
+			_this.updateEachKeyClass('full', 'off', 1000, 150, deferred.resolve);
+		}, uberDelay)
+
+		return deferred;
+	},
+
+	animateOff: function(){
+		var deferred = $.Deferred();
+
+		this.updateEachKeyClass('full off', '', 1000, 150, deferred.resolve, true);
+		
+		return deferred;
+	},
+
+	animatePress: function(){
+		var _this = this,
+			deferred = $.Deferred(),
+			len = _this.$keys.length,
+			presses = _this.randomNumbersIn(len),
+			delay = 250,
+			interval = 600;
+
+		for(var i=0; i < len; i++){
+			(function(index){
+				setTimeout(function(){
+					_this.$keys.eq(presses[index]).addClass('press');
+					if(index == len -1 ){
+						deferred.resolve();
+					}				
+				}, delay)
+
+				delay += interval;
+			}(i))
+		}
+
+		return deferred;
+	},
+
+	resetKeys: function(){
+		var _this = this,
+			len = _this.$keys.length,
+			delay = 2500,
+			interval = 250;
+
+		setTimeout(function(){
+			_this.$keys.removeClass('full press');	
+		}, delay)
+		/*for(var i=0; i < len; i++){
+			(function(index){
+				setTimeout(function(){
+					_this.$keys.eq(index).removeClass('full press');	
+				}, delay)
+
+				delay += interval;
+			}(i))
+		}*/		
+	},
+
+	updateEachKeyClass: function(clsAdd, clsRemove, delay, interval, resolve, reverse){
+		var delay = delay;
+		this.$keys.each(function(index){
+			var span = this;
+			var finishIndex = (reverse) ? 0 : 9; // final timeout at 0 or 9 depending on if class removal is reversed on the span list
+			setTimeout( function(){ 
+				$(span).removeClass(clsRemove).addClass(clsAdd);
+				if(index == finishIndex ){
+					resolve();
+				}
+			}, delay);
+
+			if(reverse){
+				delay -= interval;
+			}else{
+				delay += interval;
+			}
+		})		
+
+	},
+
+	randomNumbersIn: function(len){
+		var arr = [];
+		while(arr.length < len){
+		  	var randomnumber=Math.floor(Math.random()*len)
+		  	var found=false;
+		  	for(var i=0;i<arr.length;i++){
+				if(arr[i]==randomnumber){found=true;break}
+		  	}
+		  	if(!found)arr[arr.length]=randomnumber;
+		}
+		return arr;
+	}
+
+});
+
+window.DotLockup = DotLockup;
+
+})();
diff --git a/website/source/assets/javascripts/app/Init.js b/website/source/assets/javascripts/app/Init.js
new file mode 100644
index 000000000..49458b78e
--- /dev/null
+++ b/website/source/assets/javascripts/app/Init.js
@@ -0,0 +1,45 @@
+(function(Sidebar, CubeDraw){
+
+// Quick and dirty IE detection
+var isIE = (function(){
+	if (window.navigator.userAgent.match('Trident')) {
+		return true;
+	} else {
+		return false;
+	}
+})();
+
+// isIE = true;
+
+var Init = {
+
+	start: function(){
+		var id = document.body.id.toLowerCase();
+
+		if (this.Pages[id]) {
+			this.Pages[id]();
+		}
+
+		//always init sidebar
+		Init.initializeSidebar();
+	},
+
+	initializeSidebar: function(){
+		new Sidebar();
+	},
+
+	initializeHomepage: function(){
+		new CubeDraw();
+	},
+
+	Pages: {
+		'page-home': function(){
+			Init.initializeHomepage();
+		}
+	}
+
+};
+
+Init.start();
+
+})(window.Sidebar, window.CubeDraw);
diff --git a/website/source/assets/javascripts/app/Sidebar.js b/website/source/assets/javascripts/app/Sidebar.js
new file mode 100644
index 000000000..986f1bae9
--- /dev/null
+++ b/website/source/assets/javascripts/app/Sidebar.js
@@ -0,0 +1,51 @@
+(function(){
+
+Sidebar = Base.extend({
+
+	$body: null,
+	$overlay: null,
+	$sidebar: null,
+	$sidebarHeader: null,
+	$sidebarImg: null,
+	$toggleButton: null,
+
+	constructor: function(){
+		this.$body = $('body');
+		this.$overlay = $('.sidebar-overlay');
+    	this.$sidebar = $('#sidebar');
+    	this.$sidebarHeader = $('#sidebar .sidebar-header');
+    	this.$toggleButton = $('.navbar-toggle');
+
+    	this.sidebarImg = this.$sidebarHeader.css('background-image');
+
+		this.addEventListeners();
+	},
+
+	addEventListeners: function(){
+		var _this = this;
+
+	    _this.$toggleButton.on('click', function() {
+	        _this.$sidebar.toggleClass('open');
+	        if ((_this.$sidebar.hasClass('sidebar-fixed-left') || _this.$sidebar.hasClass('sidebar-fixed-right')) && _this.$sidebar.hasClass('open')) {
+	            _this.$overlay.addClass('active');
+	            _this.$body.css('overflow', 'hidden');
+	        } else {
+	            _this.$overlay.removeClass('active');
+	            _this.$body.css('overflow', 'auto');
+	        }
+
+	        return false;
+	    });
+
+	    _this.$overlay.on('click', function() {
+	        $(this).removeClass('active');
+	        _this.$body.css('overflow', 'auto');
+	        _this.$sidebar.removeClass('open');
+	    });
+	}
+
+});
+
+window.Sidebar = Sidebar;
+
+})();
diff --git a/website/source/assets/javascripts/application.js b/website/source/assets/javascripts/application.js
new file mode 100644
index 000000000..56b300553
--- /dev/null
+++ b/website/source/assets/javascripts/application.js
@@ -0,0 +1,11 @@
+//= require jquery
+//= require bootstrap
+//= require jquery.waypoints.min
+
+//= require lib/String.substitute
+//= require lib/Function.prototype.bind
+//= require lib/Base
+
+//= require app/Sidebar
+//= require app/CubeDraw
+//= require app/Init
diff --git a/website/source/assets/javascripts/demo.js b/website/source/assets/javascripts/demo.js
new file mode 100644
index 000000000..24d4bfd14
--- /dev/null
+++ b/website/source/assets/javascripts/demo.js
@@ -0,0 +1,9 @@
+window.Demo = Ember.Application.create({
+  rootElement: '#demo-app',
+});
+
+Demo.deferReadiness();
+
+if (document.getElementById('demo-app')) {
+  Demo.advanceReadiness();
+}
diff --git a/website/source/assets/javascripts/html5shiv.js b/website/source/assets/javascripts/html5shiv.js
new file mode 100755
index 000000000..784f221ca
--- /dev/null
+++ b/website/source/assets/javascripts/html5shiv.js
@@ -0,0 +1,8 @@
+/*
+ HTML5 Shiv v3.6.2pre | @afarkas @jdalton @jon_neal @rem | MIT/GPL2 Licensed
+*/
+(function(l,f){function m(){var a=e.elements;return"string"==typeof a?a.split(" "):a}function i(a){var b=n[a[o]];b||(b={},h++,a[o]=h,n[h]=b);return b}function p(a,b,c){b||(b=f);if(g)return b.createElement(a);c||(c=i(b));b=c.cache[a]?c.cache[a].cloneNode():r.test(a)?(c.cache[a]=c.createElem(a)).cloneNode():c.createElem(a);return b.canHaveChildren&&!s.test(a)?c.frag.appendChild(b):b}function t(a,b){if(!b.cache)b.cache={},b.createElem=a.createElement,b.createFrag=a.createDocumentFragment,b.frag=b.createFrag();
+a.createElement=function(c){return!e.shivMethods?b.createElem(c):p(c,a,b)};a.createDocumentFragment=Function("h,f","return function(){var n=f.cloneNode(),c=n.createElement;h.shivMethods&&("+m().join().replace(/\w+/g,function(a){b.createElem(a);b.frag.createElement(a);return'c("'+a+'")'})+");return n}")(e,b.frag)}function q(a){a||(a=f);var b=i(a);if(e.shivCSS&&!j&&!b.hasCSS){var c,d=a;c=d.createElement("p");d=d.getElementsByTagName("head")[0]||d.documentElement;c.innerHTML="x<style>article,aside,figcaption,figure,footer,header,hgroup,nav,section{display:block}mark{background:#FF0;color:#000}</style>";
+c=d.insertBefore(c.lastChild,d.firstChild);b.hasCSS=!!c}g||t(a,b);return a}var k=l.html5||{},s=/^<|^(?:button|map|select|textarea|object|iframe|option|optgroup)$/i,r=/^(?:a|b|code|div|fieldset|h1|h2|h3|h4|h5|h6|i|label|li|ol|p|q|span|strong|style|table|tbody|td|th|tr|ul)$/i,j,o="_html5shiv",h=0,n={},g;(function(){try{var a=f.createElement("a");a.innerHTML="<xyz></xyz>";j="hidden"in a;var b;if(!(b=1==a.childNodes.length)){f.createElement("a");var c=f.createDocumentFragment();b="undefined"==typeof c.cloneNode||
+"undefined"==typeof c.createDocumentFragment||"undefined"==typeof c.createElement}g=b}catch(d){g=j=!0}})();var e={elements:k.elements||"abbr article aside audio bdi canvas data datalist details figcaption figure footer header hgroup mark meter nav output progress section summary time video",version:"3.6.2pre",shivCSS:!1!==k.shivCSS,supportsUnknownElements:g,shivMethods:!1!==k.shivMethods,type:"default",shivDocument:q,createElement:p,createDocumentFragment:function(a,b){a||(a=f);if(g)return a.createDocumentFragment();
+for(var b=b||i(a),c=b.frag.cloneNode(),d=0,e=m(),h=e.length;d<h;d++)c.createElement(e[d]);return c}};l.html5=e;q(f)})(this,document);
diff --git a/website/source/assets/javascripts/jquery.waypoints.min.js b/website/source/assets/javascripts/jquery.waypoints.min.js
new file mode 100755
index 000000000..44a1d323c
--- /dev/null
+++ b/website/source/assets/javascripts/jquery.waypoints.min.js
@@ -0,0 +1,7 @@
+/*!
+Waypoints - 3.1.1
+Copyright © 2011-2015 Caleb Troughton
+Licensed under the MIT license.
+https://github.com/imakewebthings/waypoints/blog/master/licenses.txt
+*/
+!function(){"use strict";function t(o){if(!o)throw new Error("No options passed to Waypoint constructor");if(!o.element)throw new Error("No element option passed to Waypoint constructor");if(!o.handler)throw new Error("No handler option passed to Waypoint constructor");this.key="waypoint-"+e,this.options=t.Adapter.extend({},t.defaults,o),this.element=this.options.element,this.adapter=new t.Adapter(this.element),this.callback=o.handler,this.axis=this.options.horizontal?"horizontal":"vertical",this.enabled=this.options.enabled,this.triggerPoint=null,this.group=t.Group.findOrCreate({name:this.options.group,axis:this.axis}),this.context=t.Context.findOrCreateByElement(this.options.context),t.offsetAliases[this.options.offset]&&(this.options.offset=t.offsetAliases[this.options.offset]),this.group.add(this),this.context.add(this),i[this.key]=this,e+=1}var e=0,i={};t.prototype.queueTrigger=function(t){this.group.queueTrigger(this,t)},t.prototype.trigger=function(t){this.enabled&&this.callback&&this.callback.apply(this,t)},t.prototype.destroy=function(){this.context.remove(this),this.group.remove(this),delete i[this.key]},t.prototype.disable=function(){return this.enabled=!1,this},t.prototype.enable=function(){return this.context.refresh(),this.enabled=!0,this},t.prototype.next=function(){return this.group.next(this)},t.prototype.previous=function(){return this.group.previous(this)},t.invokeAll=function(t){var e=[];for(var o in i)e.push(i[o]);for(var n=0,r=e.length;r>n;n++)e[n][t]()},t.destroyAll=function(){t.invokeAll("destroy")},t.disableAll=function(){t.invokeAll("disable")},t.enableAll=function(){t.invokeAll("enable")},t.refreshAll=function(){t.Context.refreshAll()},t.viewportHeight=function(){return window.innerHeight||document.documentElement.clientHeight},t.viewportWidth=function(){return document.documentElement.clientWidth},t.adapters=[],t.defaults={context:window,continuous:!0,enabled:!0,group:"default",horizontal:!1,offset:0},t.offsetAliases={"bottom-in-view":function(){return this.context.innerHeight()-this.adapter.outerHeight()},"right-in-view":function(){return this.context.innerWidth()-this.adapter.outerWidth()}},window.Waypoint=t}(),function(){"use strict";function t(t){window.setTimeout(t,1e3/60)}function e(t){this.element=t,this.Adapter=n.Adapter,this.adapter=new this.Adapter(t),this.key="waypoint-context-"+i,this.didScroll=!1,this.didResize=!1,this.oldScroll={x:this.adapter.scrollLeft(),y:this.adapter.scrollTop()},this.waypoints={vertical:{},horizontal:{}},t.waypointContextKey=this.key,o[t.waypointContextKey]=this,i+=1,this.createThrottledScrollHandler(),this.createThrottledResizeHandler()}var i=0,o={},n=window.Waypoint,r=window.onload;e.prototype.add=function(t){var e=t.options.horizontal?"horizontal":"vertical";this.waypoints[e][t.key]=t,this.refresh()},e.prototype.checkEmpty=function(){var t=this.Adapter.isEmptyObject(this.waypoints.horizontal),e=this.Adapter.isEmptyObject(this.waypoints.vertical);t&&e&&(this.adapter.off(".waypoints"),delete o[this.key])},e.prototype.createThrottledResizeHandler=function(){function t(){e.handleResize(),e.didResize=!1}var e=this;this.adapter.on("resize.waypoints",function(){e.didResize||(e.didResize=!0,n.requestAnimationFrame(t))})},e.prototype.createThrottledScrollHandler=function(){function t(){e.handleScroll(),e.didScroll=!1}var e=this;this.adapter.on("scroll.waypoints",function(){(!e.didScroll||n.isTouch)&&(e.didScroll=!0,n.requestAnimationFrame(t))})},e.prototype.handleResize=function(){n.Context.refreshAll()},e.prototype.handleScroll=function(){var t={},e={horizontal:{newScroll:this.adapter.scrollLeft(),oldScroll:this.oldScroll.x,forward:"right",backward:"left"},vertical:{newScroll:this.adapter.scrollTop(),oldScroll:this.oldScroll.y,forward:"down",backward:"up"}};for(var i in e){var o=e[i],n=o.newScroll>o.oldScroll,r=n?o.forward:o.backward;for(var s in this.waypoints[i]){var a=this.waypoints[i][s],l=o.oldScroll<a.triggerPoint,h=o.newScroll>=a.triggerPoint,p=l&&h,u=!l&&!h;(p||u)&&(a.queueTrigger(r),t[a.group.id]=a.group)}}for(var c in t)t[c].flushTriggers();this.oldScroll={x:e.horizontal.newScroll,y:e.vertical.newScroll}},e.prototype.innerHeight=function(){return this.element==this.element.window?n.viewportHeight():this.adapter.innerHeight()},e.prototype.remove=function(t){delete this.waypoints[t.axis][t.key],this.checkEmpty()},e.prototype.innerWidth=function(){return this.element==this.element.window?n.viewportWidth():this.adapter.innerWidth()},e.prototype.destroy=function(){var t=[];for(var e in this.waypoints)for(var i in this.waypoints[e])t.push(this.waypoints[e][i]);for(var o=0,n=t.length;n>o;o++)t[o].destroy()},e.prototype.refresh=function(){var t,e=this.element==this.element.window,i=this.adapter.offset(),o={};this.handleScroll(),t={horizontal:{contextOffset:e?0:i.left,contextScroll:e?0:this.oldScroll.x,contextDimension:this.innerWidth(),oldScroll:this.oldScroll.x,forward:"right",backward:"left",offsetProp:"left"},vertical:{contextOffset:e?0:i.top,contextScroll:e?0:this.oldScroll.y,contextDimension:this.innerHeight(),oldScroll:this.oldScroll.y,forward:"down",backward:"up",offsetProp:"top"}};for(var n in t){var r=t[n];for(var s in this.waypoints[n]){var a,l,h,p,u,c=this.waypoints[n][s],d=c.options.offset,f=c.triggerPoint,w=0,y=null==f;c.element!==c.element.window&&(w=c.adapter.offset()[r.offsetProp]),"function"==typeof d?d=d.apply(c):"string"==typeof d&&(d=parseFloat(d),c.options.offset.indexOf("%")>-1&&(d=Math.ceil(r.contextDimension*d/100))),a=r.contextScroll-r.contextOffset,c.triggerPoint=w+a-d,l=f<r.oldScroll,h=c.triggerPoint>=r.oldScroll,p=l&&h,u=!l&&!h,!y&&p?(c.queueTrigger(r.backward),o[c.group.id]=c.group):!y&&u?(c.queueTrigger(r.forward),o[c.group.id]=c.group):y&&r.oldScroll>=c.triggerPoint&&(c.queueTrigger(r.forward),o[c.group.id]=c.group)}}for(var g in o)o[g].flushTriggers();return this},e.findOrCreateByElement=function(t){return e.findByElement(t)||new e(t)},e.refreshAll=function(){for(var t in o)o[t].refresh()},e.findByElement=function(t){return o[t.waypointContextKey]},window.onload=function(){r&&r(),e.refreshAll()},n.requestAnimationFrame=function(e){var i=window.requestAnimationFrame||window.mozRequestAnimationFrame||window.webkitRequestAnimationFrame||t;i.call(window,e)},n.Context=e}(),function(){"use strict";function t(t,e){return t.triggerPoint-e.triggerPoint}function e(t,e){return e.triggerPoint-t.triggerPoint}function i(t){this.name=t.name,this.axis=t.axis,this.id=this.name+"-"+this.axis,this.waypoints=[],this.clearTriggerQueues(),o[this.axis][this.name]=this}var o={vertical:{},horizontal:{}},n=window.Waypoint;i.prototype.add=function(t){this.waypoints.push(t)},i.prototype.clearTriggerQueues=function(){this.triggerQueues={up:[],down:[],left:[],right:[]}},i.prototype.flushTriggers=function(){for(var i in this.triggerQueues){var o=this.triggerQueues[i],n="up"===i||"left"===i;o.sort(n?e:t);for(var r=0,s=o.length;s>r;r+=1){var a=o[r];(a.options.continuous||r===o.length-1)&&a.trigger([i])}}this.clearTriggerQueues()},i.prototype.next=function(e){this.waypoints.sort(t);var i=n.Adapter.inArray(e,this.waypoints),o=i===this.waypoints.length-1;return o?null:this.waypoints[i+1]},i.prototype.previous=function(e){this.waypoints.sort(t);var i=n.Adapter.inArray(e,this.waypoints);return i?this.waypoints[i-1]:null},i.prototype.queueTrigger=function(t,e){this.triggerQueues[e].push(t)},i.prototype.remove=function(t){var e=n.Adapter.inArray(t,this.waypoints);e>-1&&this.waypoints.splice(e,1)},i.prototype.first=function(){return this.waypoints[0]},i.prototype.last=function(){return this.waypoints[this.waypoints.length-1]},i.findOrCreate=function(t){return o[t.axis][t.name]||new i(t)},n.Group=i}(),function(){"use strict";function t(t){this.$element=e(t)}var e=window.jQuery,i=window.Waypoint;e.each(["innerHeight","innerWidth","off","offset","on","outerHeight","outerWidth","scrollLeft","scrollTop"],function(e,i){t.prototype[i]=function(){var t=Array.prototype.slice.call(arguments);return this.$element[i].apply(this.$element,t)}}),e.each(["extend","inArray","isEmptyObject"],function(i,o){t[o]=e[o]}),i.adapters.push({name:"jquery",Adapter:t}),i.Adapter=t}(),function(){"use strict";function t(t){return function(){var i=[],o=arguments[0];return t.isFunction(arguments[0])&&(o=t.extend({},arguments[1]),o.handler=arguments[0]),this.each(function(){var n=t.extend({},o,{element:this});"string"==typeof n.context&&(n.context=t(this).closest(n.context)[0]),i.push(new e(n))}),i}}var e=window.Waypoint;window.jQuery&&(window.jQuery.fn.waypoint=t(window.jQuery)),window.Zepto&&(window.Zepto.fn.waypoint=t(window.Zepto))}();
\ No newline at end of file
diff --git a/website/source/assets/javascripts/lib/Base.js b/website/source/assets/javascripts/lib/Base.js
new file mode 100644
index 000000000..504e2beea
--- /dev/null
+++ b/website/source/assets/javascripts/lib/Base.js
@@ -0,0 +1,145 @@
+/*
+  Based on Base.js 1.1a (c) 2006-2010, Dean Edwards
+  Updated to pass JSHint and converted into a module by Kenneth Powers
+  License: http://www.opensource.org/licenses/mit-license.php
+*/
+/*global define:true module:true*/
+/*jshint eqeqeq:true*/
+(function (name, global, definition) {
+  if (typeof module !== 'undefined') {
+    module.exports = definition();
+  } else if (typeof define !== 'undefined' && typeof define.amd === 'object') {
+    define(definition);
+  } else {
+    global[name] = definition();
+  }
+})('Base', this, function () {
+  // Base Object
+  var Base = function () {};
+
+  // Implementation
+  Base.extend = function (_instance, _static) { // subclass
+    var extend = Base.prototype.extend;
+    // build the prototype
+    Base._prototyping = true;
+    var proto = new this();
+    extend.call(proto, _instance);
+    proto.base = function () {
+      // call this method from any other method to invoke that method's ancestor
+    };
+    delete Base._prototyping;
+    // create the wrapper for the constructor function
+    //var constructor = proto.constructor.valueOf(); //-dean
+    var constructor = proto.constructor;
+    var klass = proto.constructor = function () {
+        if (!Base._prototyping) {
+          if (this._constructing || this.constructor === klass) { // instantiation
+            this._constructing = true;
+            constructor.apply(this, arguments);
+            delete this._constructing;
+          } else if (arguments[0] !== null) { // casting
+            return (arguments[0].extend || extend).call(arguments[0], proto);
+          }
+        }
+      };
+    // build the class interface
+    klass.ancestor = this;
+    klass.extend = this.extend;
+    klass.forEach = this.forEach;
+    klass.implement = this.implement;
+    klass.prototype = proto;
+    klass.toString = this.toString;
+    klass.valueOf = function (type) {
+      return (type === 'object') ? klass : constructor.valueOf();
+    };
+    extend.call(klass, _static);
+    // class initialization
+    if (typeof klass.init === 'function') klass.init();
+    return klass;
+  };
+
+  Base.prototype = {
+    extend: function (source, value) {
+      if (arguments.length > 1) { // extending with a name/value pair
+        var ancestor = this[source];
+        if (ancestor && (typeof value === 'function') && // overriding a method?
+        // the valueOf() comparison is to avoid circular references
+        (!ancestor.valueOf || ancestor.valueOf() !== value.valueOf()) && /\bbase\b/.test(value)) {
+          // get the underlying method
+          var method = value.valueOf();
+          // override
+          value = function () {
+            var previous = this.base || Base.prototype.base;
+            this.base = ancestor;
+            var returnValue = method.apply(this, arguments);
+            this.base = previous;
+            return returnValue;
+          };
+          // point to the underlying method
+          value.valueOf = function (type) {
+            return (type === 'object') ? value : method;
+          };
+          value.toString = Base.toString;
+        }
+        this[source] = value;
+      } else if (source) { // extending with an object literal
+        var extend = Base.prototype.extend;
+        // if this object has a customized extend method then use it
+        if (!Base._prototyping && typeof this !== 'function') {
+          extend = this.extend || extend;
+        }
+        var proto = {
+          toSource: null
+        };
+        // do the "toString" and other methods manually
+        var hidden = ['constructor', 'toString', 'valueOf'];
+        // if we are prototyping then include the constructor
+        for (var i = Base._prototyping ? 0 : 1; i < hidden.length; i++) {
+          var h = hidden[i];
+          if (source[h] !== proto[h])
+            extend.call(this, h, source[h]);
+        }
+        // copy each of the source object's properties to this object
+        for (var key in source) {
+          if (!proto[key]) extend.call(this, key, source[key]);
+        }
+      }
+      return this;
+    }
+  };
+
+  // initialize
+  Base = Base.extend({
+    constructor: function () {
+      this.extend(arguments[0]);
+    }
+  }, {
+    ancestor: Object,
+    version: '1.1',
+    forEach: function (object, block, context) {
+      for (var key in object) {
+        if (this.prototype[key] === undefined) {
+          block.call(context, object[key], key, object);
+        }
+      }
+    },
+    implement: function () {
+      for (var i = 0; i < arguments.length; i++) {
+        if (typeof arguments[i] === 'function') {
+          // if it's a function, call it
+          arguments[i](this.prototype);
+        } else {
+          // add the interface using the extend method
+          this.prototype.extend(arguments[i]);
+        }
+      }
+      return this;
+    },
+    toString: function () {
+      return String(this.valueOf());
+    }
+  });
+
+  // Return Base implementation
+  return Base;
+});
diff --git a/website/source/assets/javascripts/lib/Chainable.js b/website/source/assets/javascripts/lib/Chainable.js
new file mode 100644
index 000000000..dbe51dd1d
--- /dev/null
+++ b/website/source/assets/javascripts/lib/Chainable.js
@@ -0,0 +1,92 @@
+(function(){
+
+var Chainable = function(engine){
+	this.engine = engine;
+	this._chain = [];
+	this._updateTimer = this._updateTimer.bind(this);
+	this._cycle = this._cycle.bind(this);
+};
+
+Chainable.prototype._running = false;
+
+Chainable.prototype._updateTimer = function(tick){
+	this._timer += tick;
+	if (this._timer >= this._timerMax) {
+		this.resetTimer();
+		this._cycle();
+	}
+};
+
+Chainable.prototype.resetTimer = function(){
+	this.engine.updateChainTimer = undefined;
+	this._timer = 0;
+	this._timerMax = 0;
+	return this;
+};
+
+Chainable.prototype.start = function(){
+	if (this._running || !this._chain.length) {
+		return this;
+	}
+	this._running = true;
+	return this._cycle();
+};
+
+Chainable.prototype.reset = function(){
+	if (!this._running) {
+		return this;
+	}
+	this.resetTimer();
+	this._timer = 0;
+	this._running = false;
+	return this;
+};
+
+Chainable.prototype._cycle = function(){
+	var current;
+	if (!this._chain.length) {
+		return this.reset();
+	}
+
+	current = this._chain.shift();
+
+	if (current.type === 'function') {
+		current.func.apply(current.scope, current.args);
+		current = null;
+		return this._cycle();
+	}
+	if (current.type === 'wait') {
+		this.resetTimer();
+		// Convert timer to seconds
+		this._timerMax = current.time / 1000;
+		this.engine.updateChainTimer = this._updateTimer;
+		current = null;
+	}
+
+	return this;
+};
+
+Chainable.prototype.then = Chainable.prototype.exec = function(func, scope, args){
+	this._chain.push({
+		type  : 'function',
+
+		func  : func,
+		scope : scope || window,
+		args  : args  || []
+	});
+
+	return this.start();
+};
+
+Chainable.prototype.wait = function(time){
+	this._chain.push({
+		type : 'wait',
+		time : time
+	});
+
+	return this.start();
+};
+
+window.Chainable = Chainable;
+
+})();
diff --git a/website/source/assets/javascripts/lib/Function.prototype.bind.js b/website/source/assets/javascripts/lib/Function.prototype.bind.js
new file mode 100644
index 000000000..82c3cb6c6
--- /dev/null
+++ b/website/source/assets/javascripts/lib/Function.prototype.bind.js
@@ -0,0 +1,21 @@
+if (!Function.prototype.bind) {
+	Function.prototype.bind = function (oThis) {
+		if (typeof this !== "function") {
+			throw new TypeError("Function.prototype.bind - what is trying to be bound is not callable");
+		}
+
+		var aArgs = Array.prototype.slice.call(arguments, 1),
+		fToBind = this,
+		fNOP = function () {},
+		fBound = function () {
+			return fToBind.apply(this instanceof fNOP && oThis ?
+				this : oThis,
+				aArgs.concat(Array.prototype.slice.call(arguments)));
+		};
+
+		fNOP.prototype = this.prototype;
+		fBound.prototype = new fNOP();
+
+		return fBound;
+	};
+}
diff --git a/website/source/assets/javascripts/lib/String.substitute.js b/website/source/assets/javascripts/lib/String.substitute.js
new file mode 100644
index 000000000..da2b52a38
--- /dev/null
+++ b/website/source/assets/javascripts/lib/String.substitute.js
@@ -0,0 +1,14 @@
+(function(String){
+
+if (String.prototype.substitute) {
+	return;
+}
+
+String.prototype.substitute = function(object, regexp){
+	return String(this).replace(regexp || (/\\?\{([^{}]+)\}/g), function(match, name){
+		if (match.charAt(0) == '\\') return match.slice(1);
+		return (object[name] !== null) ? object[name] : '';
+	});
+};
+
+})(String);
diff --git a/website/source/assets/javascripts/lib/dbg.js b/website/source/assets/javascripts/lib/dbg.js
new file mode 100644
index 000000000..6df4f3762
--- /dev/null
+++ b/website/source/assets/javascripts/lib/dbg.js
@@ -0,0 +1,60 @@
+/*
+ *
+ *	name: dbg
+ *
+ *	description: A bad ass little console utility, check the README for deets
+ *
+ *	license: MIT-style license
+ *
+ *	author: Amadeus Demarzi
+ *
+ *	provides: window.dbg
+ *
+ */
+
+(function(){
+
+	var global = this,
+
+		// Get the real console or set to null for easy boolean checks
+		realConsole = global.console || null,
+
+		// Backup / Disabled Lambda
+		fn = function(){},
+
+		// Supported console methods
+		methodNames = ['log', 'error', 'warn', 'info', 'count', 'debug', 'profileEnd', 'trace', 'dir', 'dirxml', 'assert', 'time', 'profile', 'timeEnd', 'group', 'groupEnd'],
+
+		// Disabled Console
+		disabledConsole = {
+
+			// Enables dbg, if it exists, otherwise it just provides disabled
+			enable: function(quiet){
+				global.dbg = realConsole ? realConsole : disabledConsole;
+			},
+
+			// Disable dbg
+			disable: function(){
+				global.dbg = disabledConsole;
+			}
+
+		}, name, i;
+
+	// Setup disabled console and provide fallbacks on the real console
+	for (i = 0; i < methodNames.length;i++){
+		name = methodNames[i];
+		disabledConsole[name] = fn;
+		if (realConsole && !realConsole[name])
+			realConsole[name] = fn;
+	}
+
+	// Add enable/disable methods
+	if (realConsole) {
+		realConsole.disable = disabledConsole.disable;
+		realConsole.enable = disabledConsole.enable;
+	}
+
+	// Enable dbg
+	disabledConsole.enable();
+
+}).call(this);
diff --git a/website/source/assets/javascripts/respond.min.js b/website/source/assets/javascripts/respond.min.js
new file mode 100755
index 000000000..56418a245
--- /dev/null
+++ b/website/source/assets/javascripts/respond.min.js
@@ -0,0 +1,6 @@
+/*! matchMedia() polyfill - Test a CSS media type/query in JS. Authors & copyright (c) 2012: Scott Jehl, Paul Irish, Nicholas Zakas. Dual MIT/BSD license */
+/*! NOTE: If you're already including a window.matchMedia polyfill via Modernizr or otherwise, you don't need this part */
+window.matchMedia=window.matchMedia||function(a){"use strict";var c,d=a.documentElement,e=d.firstElementChild||d.firstChild,f=a.createElement("body"),g=a.createElement("div");return g.id="mq-test-1",g.style.cssText="position:absolute;top:-100em",f.style.background="none",f.appendChild(g),function(a){return g.innerHTML='&shy;<style media="'+a+'"> #mq-test-1 { width: 42px; }</style>',d.insertBefore(f,e),c=42===g.offsetWidth,d.removeChild(f),{matches:c,media:a}}}(document);
+
+/*! Respond.js v1.1.0: min/max-width media query polyfill. (c) Scott Jehl. MIT/GPLv2 Lic. j.mp/respondjs  */
+(function(a){"use strict";function x(){u(!0)}var b={};a.respond=b,b.update=function(){},b.mediaQueriesSupported=a.matchMedia&&a.matchMedia("only all").matches,b.mediaQueriesSupported;var q,r,t,c=a.document,d=c.documentElement,e=[],f=[],g=[],h={},i=30,j=c.getElementsByTagName("head")[0]||d,k=c.getElementsByTagName("base")[0],l=j.getElementsByTagName("link"),m=[],n=function(){for(var b=0;l.length>b;b++){var c=l[b],d=c.href,e=c.media,f=c.rel&&"stylesheet"===c.rel.toLowerCase();d&&f&&!h[d]&&(c.styleSheet&&c.styleSheet.rawCssText?(p(c.styleSheet.rawCssText,d,e),h[d]=!0):(!/^([a-zA-Z:]*\/\/)/.test(d)&&!k||d.replace(RegExp.$1,"").split("/")[0]===a.location.host)&&m.push({href:d,media:e}))}o()},o=function(){if(m.length){var a=m.shift();v(a.href,function(b){p(b,a.href,a.media),h[a.href]=!0,setTimeout(function(){o()},0)})}},p=function(a,b,c){var d=a.match(/@media[^\{]+\{([^\{\}]*\{[^\}\{]*\})+/gi),g=d&&d.length||0;b=b.substring(0,b.lastIndexOf("/"));var h=function(a){return a.replace(/(url\()['"]?([^\/\)'"][^:\)'"]+)['"]?(\))/g,"$1"+b+"$2$3")},i=!g&&c;b.length&&(b+="/"),i&&(g=1);for(var j=0;g>j;j++){var k,l,m,n;i?(k=c,f.push(h(a))):(k=d[j].match(/@media *([^\{]+)\{([\S\s]+?)$/)&&RegExp.$1,f.push(RegExp.$2&&h(RegExp.$2))),m=k.split(","),n=m.length;for(var o=0;n>o;o++)l=m[o],e.push({media:l.split("(")[0].match(/(only\s+)?([a-zA-Z]+)\s?/)&&RegExp.$2||"all",rules:f.length-1,hasquery:l.indexOf("(")>-1,minw:l.match(/\(min\-width:[\s]*([\s]*[0-9\.]+)(px|em)[\s]*\)/)&&parseFloat(RegExp.$1)+(RegExp.$2||""),maxw:l.match(/\(max\-width:[\s]*([\s]*[0-9\.]+)(px|em)[\s]*\)/)&&parseFloat(RegExp.$1)+(RegExp.$2||"")})}u()},s=function(){var a,b=c.createElement("div"),e=c.body,f=!1;return b.style.cssText="position:absolute;font-size:1em;width:1em",e||(e=f=c.createElement("body"),e.style.background="none"),e.appendChild(b),d.insertBefore(e,d.firstChild),a=b.offsetWidth,f?d.removeChild(e):e.removeChild(b),a=t=parseFloat(a)},u=function(a){var b="clientWidth",h=d[b],k="CSS1Compat"===c.compatMode&&h||c.body[b]||h,m={},n=l[l.length-1],o=(new Date).getTime();if(a&&q&&i>o-q)return clearTimeout(r),r=setTimeout(u,i),void 0;q=o;for(var p in e)if(e.hasOwnProperty(p)){var v=e[p],w=v.minw,x=v.maxw,y=null===w,z=null===x,A="em";w&&(w=parseFloat(w)*(w.indexOf(A)>-1?t||s():1)),x&&(x=parseFloat(x)*(x.indexOf(A)>-1?t||s():1)),v.hasquery&&(y&&z||!(y||k>=w)||!(z||x>=k))||(m[v.media]||(m[v.media]=[]),m[v.media].push(f[v.rules]))}for(var B in g)g.hasOwnProperty(B)&&g[B]&&g[B].parentNode===j&&j.removeChild(g[B]);for(var C in m)if(m.hasOwnProperty(C)){var D=c.createElement("style"),E=m[C].join("\n");D.type="text/css",D.media=C,j.insertBefore(D,n.nextSibling),D.styleSheet?D.styleSheet.cssText=E:D.appendChild(c.createTextNode(E)),g.push(D)}},v=function(a,b){var c=w();c&&(c.open("GET",a,!0),c.onreadystatechange=function(){4!==c.readyState||200!==c.status&&304!==c.status||b(c.responseText)},4!==c.readyState&&c.send(null))},w=function(){var b=!1;try{b=new a.XMLHttpRequest}catch(c){b=new a.ActiveXObject("Microsoft.XMLHTTP")}return function(){return b}}();n(),b.update=n,a.addEventListener?a.addEventListener("resize",x,!1):a.attachEvent&&a.attachEvent("onresize",x)})(this);
diff --git a/website/source/assets/stylesheets/_api.scss b/website/source/assets/stylesheets/_api.scss
new file mode 100644
index 000000000..9bbffe6aa
--- /dev/null
+++ b/website/source/assets/stylesheets/_api.scss
@@ -0,0 +1,51 @@
+//
+// API
+// --------------------------------------------------
+
+.bs-api-section dl, dl.api {
+    margin-top: 30px;
+    line-height: 20px;
+
+    dt {
+        color: #888;
+        text-transform: uppercase;
+        font-weight: normal;
+        float: left;
+        width: 150px;
+        text-align: right;
+    }
+
+    dd {
+        margin-left: 170px;
+
+        pre.api-sample {
+            margin-top: 20px;
+            font-size: 14px;
+            padding: 10px;
+        }
+    }
+
+    ul {
+        margin: 0;
+        padding: 0;
+
+        li {
+            margin: 0;
+            list-style-type: none;
+            padding-bottom: 20px;
+            font-size: 15px;
+            font-family: "Lato", "Helvetica Neue", Helvetica, Arial, sans-serif;
+            font-weight: 500;
+
+            span.param {
+                font-weight: bold;
+            }
+
+            span.param-flags {
+                font-style: italic;
+                color: #888;
+                padding-right: 6px;
+            }
+        }
+    }
+}
diff --git a/website/source/assets/stylesheets/_buttons.scss b/website/source/assets/stylesheets/_buttons.scss
new file mode 100755
index 000000000..a9906066c
--- /dev/null
+++ b/website/source/assets/stylesheets/_buttons.scss
@@ -0,0 +1,119 @@
+//
+// Button Styles
+// --------------------------------------------------
+
+.h-btn{
+	display: inline-block;
+	background-color: $white;
+	color: $black;
+	@include transition(color .3s ease-in-out);
+	//@include btn-shadow();
+	font-family: $font-family-blanc-reg;
+	text-transform: uppercase;
+	border-radius: 3px;
+
+	&.has-caret{
+		span.h-caret{
+			display: inline-block;
+			width: 8px;
+			height: 12px;
+			margin-left: 10px;
+			@include transition(all 300ms ease-in);
+		}
+	}
+
+	&.lrg{
+		font-size: $font-size-reg;
+		padding: 10px 24px;
+	}
+
+	&.sml{
+		padding: 8px 14px;
+		font-size: $font-size-reg - 2;
+	    line-height: 14px;
+
+		&.has-caret{
+			span.h-caret{
+				background-size: 6px 9px !important;
+				margin-bottom: -2px;
+				margin-right: -3px;
+			}
+		}
+	}
+
+	&.light{
+		color: $green-light;
+
+		&.has-border{
+			border: 2px solid $green-light;
+		}
+
+		&.has-caret{
+			span.h-caret{
+				background: image-url('../images/caret-light.png') 0 0 no-repeat;
+				@include img-retina("../images/caret-light.png", "../images/caret-light@2x.png", 8px, 12px);
+			}
+		}
+	}
+
+	&.green{
+		color: $green;
+
+		&.has-border{
+			border: 2px solid $green;
+		}
+
+		span.h-caret{
+			background: image-url('../images/caret-green.png') 0 0 no-repeat;
+			@include img-retina("../images/caret-green.png", "../images/caret-green@2x.png", 8px, 12px);
+		}
+
+		&.fill{
+			background-color: $green;
+			color: $white;
+
+			span.h-caret{
+				background: image-url('../images/caret-white.png') 0 0 no-repeat;
+				@include img-retina("../images/caret-white.png", "../images/caret-white@2x.png", 8px, 12px);
+			}
+		}
+	}
+
+	&.gray{
+		color: $blue-light;
+
+		&.border{
+			border: 2px solid $blue-light;
+		}
+
+		&.fill{
+			background-color: $blue-light;
+			color: $white;
+
+			span.h-caret{
+				background: image-url('../images/caret-white.png') 0 0 no-repeat;
+				@include img-retina("../images/caret-white.png", "../images/caret-white@2x.png", 8px, 12px);
+			}
+		}
+	}
+
+	&.dark{
+		color: $green-dark;
+
+		&.border{
+			border: 2px solid $green-dark;
+		}
+	}
+
+	&:hover{
+		text-decoration: none;
+		@include transition(color 200ms ease-in);
+
+		&.has-caret{
+			span.h-caret{
+				@include translate(4px, 0);
+				@include transition(all 200ms ease-in);
+			}
+		}
+	}
+}
diff --git a/website/source/assets/stylesheets/_community.scss b/website/source/assets/stylesheets/_community.scss
new file mode 100644
index 000000000..280360058
--- /dev/null
+++ b/website/source/assets/stylesheets/_community.scss
@@ -0,0 +1,21 @@
+.people {
+    margin-top: 30px;
+
+    .person {
+        margin-bottom: 40px;
+
+        h3 {
+            color: $blue-dark;
+            text-transform: none;
+        }
+
+        img {
+            width: 125px;
+            margin: auto auto;
+        }
+
+        .bio {
+            padding-left: 150px;
+        }
+    }
+}
diff --git a/website/source/assets/stylesheets/_docs.scss b/website/source/assets/stylesheets/_docs.scss
new file mode 100755
index 000000000..bc5ce4c6b
--- /dev/null
+++ b/website/source/assets/stylesheets/_docs.scss
@@ -0,0 +1,283 @@
+//
+// Docs
+// --------------------------------------------------
+
+body.layout-atlas,
+body.layout-consul,
+body.layout-dnsimple,
+body.layout-dme,
+body.layout-cloudflare,
+body.layout-cloudstack,
+body.layout-google,
+body.layout-heroku,
+body.layout-mailgun,
+body.layout-digitalocean,
+body.layout-aws,
+body.layout-docs,
+body.layout-inner,
+body.layout-downloads,
+body.layout-intro{
+	//background: $light-black image-url('sidebar-wire.png') left 62px no-repeat;
+	>.container{
+		.col-md-8[role=main]{
+			min-height: 800px;
+			background-color: white;
+
+			>div{
+				position: relative;
+				z-index: 10;
+			}
+		}
+	}
+}
+
+.docs-sidebar{
+  	position: relative;
+  	z-index: 20;
+  	margin-bottom: 30px;
+	margin-top: 50px;
+	margin-right: 4%;
+	@include open();
+
+	.nav.docs-sidenav{
+		padding-bottom: 15px;
+
+		:last-child{
+			border-bottom: none;
+		}
+
+		//all li
+		li{
+			position: relative;
+
+			> a{
+				padding: 10px 0 10px 8px;
+				font-size: 15px;
+				color: $blue-dark;
+
+				&:before{
+					@include bez-1-transition();
+				}
+
+				&:hover{
+					background-color: transparent !important;
+
+					&:before{
+						@include bez-1-transition();
+					}
+				}
+			}
+		}
+
+		$parent-active-state: -14px;
+		$parent-default-state: -10px;
+		$child-active-state: -4px;
+		$child-default-state: 0px;
+
+		//first teir li
+		> li {
+			margin: 0 0 0 10px;
+
+			&.active {
+				>a{
+					color: $green-dark;
+					font-weight: 600;
+					border-right: 1px solid $green-faint;
+
+					&:hover{
+						&:before{
+							left: $parent-default-state;
+						}
+					}
+
+					&:before{
+						@include rotate(90deg);
+						opacity: 1;
+					}
+				}
+
+				.nav {
+					display: block;
+				}
+			}
+
+			> a {
+        		-webkit-font-smoothing: antialiased;
+
+				&:hover{
+					&:before{
+						left: $parent-active-state;
+					}
+				}
+
+				&:before{
+					content: '';
+					position: absolute;
+			        width: 8px;
+			        height: 12px;
+					top: 15px;
+					left: $parent-default-state;
+					overflow: hidden;
+					background: url(../images/caret-green.png) 0 0 no-repeat;
+					opacity: .3;
+					@include img-retina("../images/caret-light.png", "../images/caret-light@2x.png", 6px, 9px);
+				}
+			}
+		}
+
+		//nested ul.nav
+		.nav {
+			display: none;
+			padding-top: 10px;
+			padding-bottom: 10px;
+			margin-bottom: 15px;
+			border-right: 1px solid $green-faint;
+		    border-bottom: 1px solid $green-faint;
+
+			> li{
+				margin-left: 10px;
+
+				&.active{
+					> a{
+		            	color: $green-dark;
+						font-weight: 600;
+
+						&:hover{
+							&:before{
+								left: $child-default-state;
+							}
+						}
+
+						&:before{
+							//background: url(../images/triangle-sprite.png) 0 0 no-repeat;
+							//@include img-retina("../images/triangle-sprite.png", "../images/triangle-sprite@2x.png", 5px, 19px);
+						}
+					}
+				}
+
+				> a{
+          			-webkit-font-smoothing: antialiased;
+					padding: 6px 15px;
+
+					&:hover{
+						&:before{
+							left: $child-active-state;
+						}
+					}
+
+					&:before{
+						opacity: .75;
+						content: '';
+						position: absolute;
+				        width: 5px;
+				        height: 7px;
+						top: 12px;
+						left: $child-default-state;
+						overflow: hidden;
+						//background: url(../images/triangle-sprite.png) 0 -13px no-repeat;
+						//@include img-retina("../images/triangle-sprite.png", "../images/triangle-sprite@2x.png", 5px, 19px);
+					}
+				}
+			}
+		}
+
+        .nav-visible {
+            display: block;
+        }
+	}
+}
+
+
+.bs-docs-section{
+	padding-top: 10px;
+	padding-left: 3%;
+	padding-bottom: 80px;
+
+	.lead{
+		margin-bottom: 48px
+	}
+
+	.doc-sectional{
+		margin-bottom: 48px;
+	}
+
+	p, li, .alert {
+		color: $blue-dark;
+		font-size: 18px;
+		font-family: $font-family-open-sans;
+		font-weight: $font-weight-reg;
+    	line-height: 1.84em;
+		margin: 0 0 18px;
+    	-webkit-font-smoothing: antialiased;
+	}
+
+    pre{
+        margin: 0 0 18px;
+    }
+
+	a{
+		color: $green-dark;
+		border-bottom: 1px solid $green-dark;
+		@include transition(all 300ms ease-in);
+
+		&:hover{
+			color: $blue-dark;
+			border-bottom: 2px solid $blue-dark;
+			text-decoration: none;
+			@include transition(all 300ms ease-in);
+		}
+	}
+
+    img{
+        max-width: 650px;
+        margin-top: 25px;
+        margin-bottom: 25px;
+    }
+
+	h1, .h1, h2, .h2, h3, .h3, h4, .h4{
+		color: $gray-dark;
+		margin-top: 54px;
+		margin-bottom: 18px;
+    	@include open-sb();
+	}
+
+	h1{
+		font-size: 36px;
+	}
+
+    #graph {
+        margin-top: 30px;
+    }
+}
+
+
+@media (max-width: 992px) {
+
+  .bs-docs-section{
+  	  padding-left: 0;
+  }
+}
+
+@media (max-width: 768px) {
+	.bs-docs-section{
+		padding-top: 0;
+		h1{
+			margin-top: 0;
+		}
+	}
+}
+
+
+
+
+@media (max-width: 480px) {
+	.bs-docs-section{
+        img{
+            max-width: 450px;
+        }
+
+		h1{
+			font-size: 32px;
+		}
+	}
+}
diff --git a/website/source/assets/stylesheets/_downloads.scss b/website/source/assets/stylesheets/_downloads.scss
new file mode 100644
index 000000000..be2187eaf
--- /dev/null
+++ b/website/source/assets/stylesheets/_downloads.scss
@@ -0,0 +1,59 @@
+.downloads {
+    margin-top: 20px;
+
+    .description {
+        margin-bottom: 20px;
+    }
+
+    .download {
+        border-bottom: 1px solid #b2b2b2;
+        padding-bottom: 15px;
+        margin-top: 10px;
+        margin-bottom: 10px;
+
+        .details {
+            padding-left: 95px;
+
+            h2 {
+                margin-top: 30px;
+            }
+
+            ul {
+                padding-left: 0px;
+            }
+
+            li {
+                display: inline-block;
+
+                &:after {
+                    content: " | ";
+                }
+
+                &:last-child:after {
+                    content: "";
+                }
+            }
+        }
+
+        .icon {
+            img {
+                width: 75px;
+            }
+        }
+
+        .os-name {
+            font-size: 40px;
+            margin-bottom: -3px;
+        }
+    }
+
+    .poweredby {
+        margin-top: 20px;
+
+        img {
+            display: block;
+            margin: 0 auto;
+            width: 122px;
+        }
+    }
+}
diff --git a/website/source/assets/stylesheets/_footer.scss b/website/source/assets/stylesheets/_footer.scss
new file mode 100644
index 000000000..ad5b97160
--- /dev/null
+++ b/website/source/assets/stylesheets/_footer.scss
@@ -0,0 +1,116 @@
+body.page-sub{
+    #footer{
+        padding: 0 0 40px 0;
+        .col-md-5{
+            padding-top: 40px;
+            border-top: 1px solid $faint-gray;
+        }
+    }
+}
+
+#footer{
+    padding: 40px 0;
+    color: black;
+
+    .footer-links{
+        margin-bottom: 20px;
+
+        .li-under a:hover::after,
+        .li-under a:focus::after {
+            opacity: 1;
+            -webkit-transform: skewY(15deg) translateY(8px);
+            -moz-transform: skewY(15deg) translateY(8px);
+            transform: skewY(15deg) translateY(8px);
+        }
+
+        .li-under a::after {
+            background-color: $purple;
+        }
+
+        li{
+            a{
+                @include v-nav-style();
+            }
+        }
+    }
+
+    .pull-right{
+        padding-right: 15px;
+    }
+
+    .footer-hashi{
+        font-size: 14px;
+
+        a{
+            color: black;
+            font-weight: 600;
+        }
+
+        span{
+            margin-right: 4px;
+        }
+
+        .hashi-logo{
+            display: inline-block;
+            vertical-align: middle;
+            i{
+                display: inline-block;
+                margin-top: -2px;
+                width: 27px;
+                height: 28px;
+                background: image-url('../images/hashi-logo.png') 0 0 no-repeat;
+                @include img-retina('../images/hashi-logo.png', '../images/hashi-logo@2x.png', 27px, 28px);
+            }
+        }
+    }
+}
+
+@media (max-width: 992px) {
+
+}
+
+@media (max-width: 768px) {
+
+    body.page-sub{
+        #footer{
+            .col-md-5{
+                &:last-child{
+                    padding-top: 0;
+                    border-top: none;
+                }
+            }
+        }
+    }
+
+    #footer{
+        padding: 100px 0 40px;
+        text-align: center;
+
+        .footer-links{
+            float: none;
+            display: inline-block;
+        }
+
+        .footer-hashi {
+            float: none;
+            display: inline-block;
+
+            .pull-right{
+                float: none !important;
+            }
+        }
+    }
+}
+
+@media (max-width: 320px) {
+
+    #footer{
+        text-align: center;
+
+        .footer-links{
+            .li-under{
+                float: none !important;
+            }
+        }
+    }
+}
diff --git a/website/source/assets/stylesheets/_global.scss b/website/source/assets/stylesheets/_global.scss
new file mode 100755
index 000000000..c95a8ec5a
--- /dev/null
+++ b/website/source/assets/stylesheets/_global.scss
@@ -0,0 +1,90 @@
+//
+// Global Site
+// --------------------------------------------------
+
+/*html{
+  text-rendering: optimizeLegibility;
+  -webkit-font-smoothing: antialiased;
+}*/
+
+body {
+    -webkit-font-smoothing: antialiased;
+    color: $black;
+    background-color: $white;
+    font-size: 15px;
+    font-family: $font-family-open-sans;
+    font-weight: 500;
+}
+
+
+h1, h2, h3, h4, h5 {
+    -webkit-font-smoothing: antialiased;
+}
+h1{
+	font-size: 42px;
+	line-height: 42px;
+	font-family: $font-family-open-sans;
+	font-weight: $font-weight-reg;
+	margin-bottom: 24px;
+}
+
+h3{
+	font-size: 28px;
+	line-height: 28px;
+	font-family: $font-family-open-sans;
+	font-weight: $font-weight-reg;
+}
+
+//an alternative color for buttons in the doc body
+.btn-serf{
+	color: $white !important;
+	background-color: $btn-color;
+	border-radius: $btn-border-radius;
+	//@include box-shadow( $shadow );
+}
+
+.highlight{
+	margin-bottom: 18px;
+}
+
+pre {
+	background-color: $black;
+	color: $white;
+	font-size: 14px;
+	font-weight: normal;
+	font-family: "Courier New", Monaco, Menlo, Consolas, monospace;
+	border: none;
+	padding: 20px;
+	margin-bottom: 0;
+}
+
+
+//fixed grid below 992 to prevent smaller responsive sizes
+@media (max-width: 992px) {
+	.container{
+		max-width: 970px;
+	}
+}
+
+//all below styles are overriding corrections for below (min-width: 992px)
+//below (min-width: 992px) these styles change
+.navbar-nav {
+	margin: 0;
+}
+
+.navbar-right {
+	float: right !important;
+}
+
+.navbar-nav > li {
+	float: left;
+}
+
+.navbar-nav > li > a {
+	padding-top: 15px;
+	padding-bottom: 15px;
+}
+
+.center {
+    text-align: center;
+}
diff --git a/website/source/assets/stylesheets/_header.scss b/website/source/assets/stylesheets/_header.scss
new file mode 100755
index 000000000..0d8980a09
--- /dev/null
+++ b/website/source/assets/stylesheets/_header.scss
@@ -0,0 +1,131 @@
+//
+// Header
+// --------------------------------------------------
+
+#header {
+    position: relative;
+    color: $white;
+    text-rendering: optimizeLegibility;
+    margin-bottom: 0;
+    /* opacity: 0;
+    @include translate3d(0, -10px, 0); */
+    transition: all 1s ease;
+
+    /* &.showit{
+        opacity: 1;
+        @include translate3d(0, 0px, 0);
+        transition: all 1s ease;
+    } */
+
+    &.navbar-static-top{
+        height:70px;
+        z-index: 1000;
+    }
+
+    .navbar-header{
+
+        .navbar-toggle{
+            padding-right: 15px;
+            margin-top: 26px;
+            margin-bottom: 14px;
+            margin-right: 0;
+            //border: 2px solid $white;
+            border-radius: 0;
+            .icon-bar{
+                border: 1px solid $black;
+                border-radius: 0;
+            }
+        }
+    }
+
+
+    .navbar-brand {
+        display: inline-block;
+        padding: 0;
+        margin: 30px 10px 0 0 ;
+
+        .logo{
+            display: inline-block;
+            height: 56px;
+            padding: 0;
+            color: $gray-darker;
+            font-family: $font-family-blanc;
+            font-size: 28px;
+            line-height: 56px;
+            padding-left: 60px;
+            background: image-url('../images/logo-header.png') 0 0 no-repeat;
+            @include img-retina("../images/logo-header.png", "../images/logo-header@2x.png", 49px, 56px);
+
+            &:hover{
+				@include transition(all 300ms ease-in);
+				color: $green-dark;
+				text-decoration: none;
+			}
+        }
+    }
+
+    .main-links.navbar-nav{
+        margin-top: 50px;
+        margin-left: 120px;
+
+        li > a {
+            @include v-nav-style();
+        }
+    }
+
+    .buttons{
+        ul.navbar-nav{
+            margin-top: 50px;
+            li {
+              padding-left: 12px;
+
+              &.download{
+                background: image-url('../images/icon-download.png') 0 0 no-repeat;
+                @include img-retina("../images/icon-download.png", "../images/icon-download@2x.png", 18px, 18px);
+                margin-right: 22px;
+                background-position: 0 1px;
+              }
+
+              &.github{
+                background: image-url('../images/icon-github.png') 0 0 no-repeat;
+                @include img-retina("../images/icon-github.png", "../images/icon-github@2x.png", 19px, 18px);
+                background-position: 0 1px;
+              }
+
+              >a {
+                    @include v-nav-style();
+                }
+            }
+        }
+    }
+
+    .nav > li > a:hover, .nav > li > a:focus {
+        background-color: transparent;
+        color: $black;
+        @include transition( color 0.3s ease );
+    }
+}
+
+@media (min-width: 992px) {
+
+}
+
+@media (max-width: 992px) {
+
+}
+
+@media (max-width: 768px) {
+
+}
+
+@media (max-width: 763px) {
+    .navbar-static-top {
+        .nav-white {
+            background-color:rgba(0,0,0,0.5);
+        }
+    }
+}
+
+@media (max-width: 320px) {
+
+}
diff --git a/website/source/assets/stylesheets/_home.scss b/website/source/assets/stylesheets/_home.scss
new file mode 100755
index 000000000..aeca3ec4e
--- /dev/null
+++ b/website/source/assets/stylesheets/_home.scss
@@ -0,0 +1,490 @@
+//
+// Home
+// --------------------------------------------------
+
+#hero{
+	@include translate3d(0, -10px, 0);
+	text-align: center;
+
+	#hero-graphic{
+		position: relative;
+		display: inline-block;
+		width: 499px;
+		height: 340px;
+		margin: 120px auto;
+
+		#hero-logotype{
+			position: absolute;
+			display: inline-block;
+		    top: 75px;
+		    left: 187px;
+			width: 115px;
+			height: 155px;
+			background: image-url('../images/hero-logotype.png') 0 0 no-repeat;
+			@include img-retina("../images/hero-logotype.png", "../images/hero-logotype@2x.png", 115px, 155px);
+		}
+
+		#cubes{
+			.cube{
+				position: absolute;
+			  	top: 300px;
+			  	left: 248px;
+				opacity: 0.01;
+				@include transform( translate(0, 150px) );
+				@include transition( all 1.5s $easeInOutBack );
+
+				&.in{
+				  	@include transform( translate(0, 0) );
+				  	opacity: 1;
+				}
+
+				.face {
+				  	@include transform-origin(0 0);
+				  	position: absolute;
+				  	height: 44px;
+				  	width: 44px;
+
+					&.top{
+						background-color: $green;
+						@include transform(rotate(210deg) skewX(-30deg) scaleY(0.864) );
+					}
+					&.left{
+						background-color: $green-dark;
+						@include transform(rotate(90deg) skewX(-30deg) scaleY(0.864) );
+					}
+					&.right{
+						background-color: $green-light;
+						@include transform(rotate(-30deg) skewX(-30deg) scaleY(0.864) );
+					}
+				}
+			}
+		}
+	}
+
+	#hero-text{
+		position: relative;
+		text: center;
+
+		h1{
+			color: $blue-dark;
+			font-size: $font-size-xl;
+			font-family: $font-family-blanc;
+		}
+
+		h3{
+			color: $blue-light;
+			font-size: $font-size-m;
+			font-family: $font-family-blanc;
+		}
+
+		#hero-btns{
+			margin-top: 26px;
+			a{
+
+			}
+		}
+	}
+
+	#tag-line{
+		margin: 15px 0 20px 0;
+		font-size: 24px;
+		font-weight: 300;
+	}
+
+	p{
+		margin-top: 60px;
+		text-align: left;
+		font-size: 18px;
+		font-weight: 300;
+		line-height: 2em;
+
+		.strong{
+			font-size: 20px;
+			font-weight: 500;
+		}
+	}
+}
+
+.banner{
+	margin-top: 120px;
+
+	&.gray-banner{
+		.col{
+			border: 1px solid $blue-faint;
+		}
+
+		p{
+			color: $blue-light;
+		}
+	}
+
+	&.green-banner{
+		.col{
+			border: 1px solid $blue-faint;
+		}
+
+		p{
+			color: $blue-dark;
+		}
+	}
+
+	&#cta-banner{
+		margin-top: 0;
+		margin-bottom: 80px;
+
+		.col{
+			padding: 60px 20px;
+		}
+	}
+
+	.col{
+		padding: 20px;
+		text-align: center;
+		border-radius: 3px;
+	}
+
+	p{
+		margin-bottom: 0px;
+		margin-right: 30px;
+		font-size: $font-size-reg;
+		line-height: $font-size-reg;
+		font-family: $font-family-blanc-reg;
+	}
+
+	p, a{
+		display: inline-block;
+	}
+}
+
+#content{
+	overflow: hidden;
+	margin-top: 120px;
+
+	h2{
+		margin-bottom: 120px;
+		text-align: center;
+		font-size: $font-size-m;
+		font-family: $font-family-blanc;
+		color: $green;
+		text-transform: uppercase;
+	}
+
+	.feature{
+		position: relative;
+		margin-bottom: 150px;
+		padding-bottom: 80px;
+		border-bottom: 1px solid $blue-faint;
+
+		&:last-child{
+			border-bottom: none;
+		}
+
+		&#deploy{
+			padding-bottom: 835px;
+			width: 1161px;
+			height: 735px;
+			background: image-url('../images/feature-deploy.png') 0 0 no-repeat;
+			@include img-retina("../images/feature-deploy.png", "../images/feature-deploy@2x.png", 1161px, 735px);
+		}
+
+		&#maintain{
+			.feature-graphic{
+				margin-top: -50px;
+				width: 1113px;
+				height: 689px;
+				background: image-url('../images/feature-manage.png') 0 0 no-repeat;
+				@include img-retina("../images/feature-manage.png", "../images/feature-manage@2x.png", 1113px, 689px);
+			}
+		}
+
+		&#healing{
+			.feature-graphic{
+				margin-top: 80px;
+				width: 1009px;
+				height: 309px;
+				background: image-url('../images/feature-healing.png') 0 0 no-repeat;
+				@include img-retina("../images/feature-healing.png", "../images/feature-healing@2x.png", 1009px, 309px);
+			}
+		}
+
+		&#density{
+			.feature-graphic{
+				margin-top: 80px;
+				width: 1040px;
+				height: 409px;
+				background: image-url('../images/feature-density.png') 0 0 no-repeat;
+				@include img-retina("../images/feature-density.png", "../images/feature-density@2x.png", 1040px, 409px);
+			}
+		}
+
+		&#partners{
+			.partner-logos{
+				.docker-wrap{
+					border-right: 1px solid $blue-faint;
+
+					.partner-logo{
+						display: inline-block;
+						width: 120px;
+						height: 180px;
+
+						&.docker-logo{
+			    			background: image-url('../images/partner-docker.png') center center no-repeat;
+			   				@include img-retina("../images/partner-docker.png", "../images/partner-docker@2x.png", 100px, 84px);
+						}
+					}
+				}
+
+				.cloud-wrap{
+					.partner-logo{
+						float: left;
+						width: 25%;
+						height: 180px;
+
+						&.aws-logo{
+			    			background: image-url('../images/partner-amazon.png') center center no-repeat;
+			   				@include img-retina("../images/partner-amazon.png", "../images/partner-amazon@2x.png", 153px, 56px);
+						}
+						&.google-logo{
+			    			background: image-url('../images/partner-google.png') center center no-repeat;
+			   				@include img-retina("../images/partner-google.png", "../images/partner-google@2x.png", 135px, 87px);
+						}
+						&.microsoft-logo{
+			    			background: image-url('../images/partner-microsoft.png') center center no-repeat;
+			   				@include img-retina("../images/partner-microsoft.png", "../images/partner-microsoft@2x.png", 188px, 84px);
+						}
+						&.engineyard-logo{
+			    			background: image-url('../images/partner-engineyard.png') center center no-repeat;
+			   				@include img-retina("../images/partner-engineyard.png", "../images/partner-engineyard@2x.png", 178px, 37px);
+						}
+
+					}
+				}
+			}
+		}
+
+		&#audit{
+			.graphic{
+				width: 491px;
+				height: 129px;
+			    background: image-url('../images/graphic-audit.png') 0 0 no-repeat;
+			   	@include img-retina("../images/graphic-audit.png", "../images/graphic-audit@2x.png", 491px, 129px);
+			}
+		}
+
+		.feature-graphic{
+			margin: 0 auto;
+		}
+
+		.feature-header{
+
+			&.right{
+				h3, p{
+					text-align: right;
+					display: block;
+					float: right;
+				}
+			}
+
+			h3{
+				margin: 30px 0 20px 0;
+				color: $blue-dark;
+				letter-spacing: 1px;
+				font-size: $font-size-l;
+				font-family: $font-family-blanc;
+				line-height: 1.25em;
+				max-width: 640px;
+			}
+
+			p{
+				margin-bottom: 30px;
+				color: $blue-light;
+				font-size: $font-size-reg+2;
+				font-family: $font-family-blanc-reg;
+				line-height: 1.75em;
+				max-width: 480px;
+			}
+		}
+
+		.feature-footer{
+			position: absolute;
+			bottom: 0;
+			left: 0;
+			padding-bottom: 80px;
+
+			p{
+				display: inline-block;
+				color: $blue-dark;
+				font-size: $font-size-reg;
+				font-family: $font-family-blanc;
+				line-height: 1.75em;
+				max-width: 320px;
+				padding-left: 20px;
+				border-left: 1px solid $blue-faint;
+			}
+
+			.docker-outline-logo{
+				display: inline-block;
+				width: 125px;
+				height: 80px;
+				margin-right: 20px;
+			    background: image-url('../images/icon-docker-outline.png') 0 0 no-repeat;
+			   	@include img-retina("../images/icon-docker-outline.png", "../images/icon-docker-outline@2x.png", 125px, 80px);
+			}
+
+			a{
+				margin-bottom: 15px;
+				margin-left: 15px;
+
+				&:first-child{
+					margin-left: 0;
+				}
+			}
+		}
+	}
+
+	#cta {
+		position: relative;
+		padding: 160px 0;
+		background: image-url('../images/bg-iconscrud.png') center center no-repeat;
+		@include img-retina("../images/bg-icons.png", "../images/bg-icons@2x.png", 669px, 260px);
+		background-position: center center;
+		border-top: 1px solid $faint-gray;
+		border-bottom: 1px solid $faint-gray;
+
+		a{
+			margin-bottom: 5px;
+		}
+
+		p{
+			margin-top: 10px;
+			color: $black;
+			font-size: 14px;
+			font-weight: 600;
+	    	line-height: 1.5esm;
+
+	    	&.cta-gray{
+	    		color: $gray;
+	    		font-weight: 300;
+	    	}
+		}
+
+		.outline-btn {
+			padding: 16px 40px;
+			display: inline-block;
+			&:focus {
+		    	outline: 0;
+			}
+		}
+	}
+}
+
+@media (min-width: 1200px) {
+
+}
+
+
+@media (max-width: 1200px) {
+
+}
+
+@media (min-width: 992px) and (max-width:1200px) {
+	#cta a {
+		margin-top: 15px;
+		font-size: 18px;
+	}
+}
+
+@media (min-width: 768px) and (max-width:992px) {
+	#cta a {
+		margin-top: 10px;
+	}
+}
+
+@media (max-width: 992px) {
+
+}
+
+@media (max-width: 768px) {
+	#cta{
+		.intro{
+			text-align: center;
+			p{
+				text-align: center;
+				margin-bottom: 15px;
+			}
+		}
+	}
+}
+
+
+@media (max-width: 480px) {
+	#hero{
+		#diagram{
+			width: 100%;
+			height: 132px;
+		    background: image-url('../images/hero.png') center 0 no-repeat;
+		   	@include img-retina("../images/hero.png", "../images/hero@2x.png", 320px, 132px);
+		}
+	}
+
+	#content{
+		.feature{
+			&#audit{
+				.graphic{
+					width: 100%;
+					height: 84px;
+				    background: image-url('../images/graphic-audit.png') center 0 no-repeat;
+				   	@include img-retina("../images/graphic-audit.png", "../images/graphic-audit@2x.png", 320px, 84px);
+				}
+			}
+		}
+	}
+
+	.feature-footer{
+		text-align: center;
+		a{
+			margin-bottom: 15px;
+			margin-left: 0 !important;
+		}
+	}
+}
+
+
+@media (max-width: 320px) {
+
+	#hero{
+		#diagram{
+			width: 100%;
+			height: 132px;
+		    background: image-url('../images/hero.png') center 0 no-repeat;
+		   	@include img-retina("../images/hero.png", "../images/hero@2x.png", 320px, 132px);
+		}
+	}
+
+	#content{
+		.feature{
+			&#crud{
+				.graphic{
+					width: 100%;
+					height: 111px;
+				    background: image-url('../images/graphic-crud.png') center 0 no-repeat;
+				   	@include img-retina("../images/graphic-crud.png", "../images/graphic-crud@2x.png", 290px, 111px);
+				}
+			}
+
+			&#audit{
+				.graphic{
+					width: 100%;
+					height: 76px;
+				    background: image-url('../images/graphic-audit.png') center 0 no-repeat;
+				   	@include img-retina("../images/graphic-audit.png", "../images/graphic-audit@2x.png", 290px, 76px);
+				}
+			}
+		}
+	}
+
+	#cta a {
+		font-size: 14px;
+		font-weight: 400;
+	}
+}
diff --git a/website/source/assets/stylesheets/_mixins.scss b/website/source/assets/stylesheets/_mixins.scss
new file mode 100755
index 000000000..46f7bb2f7
--- /dev/null
+++ b/website/source/assets/stylesheets/_mixins.scss
@@ -0,0 +1,762 @@
+//
+// Mixins
+// --------------------------------------------------
+
+
+// Utilities
+// -------------------------
+
+// Clearfix
+// Source: http://nicolasgallagher.com/micro-clearfix-hack/
+//
+// For modern browsers
+// 1. The space content is one way to avoid an Opera bug when the
+//    contenteditable attribute is included anywhere else in the document.
+//    Otherwise it causes space to appear at the top and bottom of elements
+//    that are clearfixed.
+// 2. The use of `table` rather than `block` is only necessary if using
+//    `:before` to contain the top-margins of child elements.
+@mixin clearfix() {
+  &:before,
+  &:after {
+    content: " "; /* 1 */
+    display: table; /* 2 */
+  }
+  &:after {
+    clear: both;
+  }
+}
+
+// Webkit-style focus
+@mixin tab-focus() {
+  // Default
+  outline: thin dotted #333;
+  // Webkit
+  outline: 5px auto -webkit-focus-ring-color;
+  outline-offset: -2px;
+}
+
+// Center-align a block level element
+@mixin center-block() {
+  display: block;
+  margin-left: auto;
+  margin-right: auto;
+}
+
+// Sizing shortcuts
+@mixin size($width, $height) {
+  width: $width;
+  height: $height;
+}
+@mixin square($size) {
+  @include size($size, $size);
+}
+
+// Placeholder text
+@mixin placeholder($color: $input-color-placeholder) {
+  &:-moz-placeholder            { color: $color; } // Firefox 4-18
+  &::-moz-placeholder           { color: $color; } // Firefox 19+
+  &:-ms-input-placeholder       { color: $color; } // Internet Explorer 10+
+  &::-webkit-input-placeholder  { color: $color; } // Safari and Chrome
+}
+
+// Text overflow
+// Requires inline-block or block for proper styling
+@mixin text-overflow() {
+  overflow: hidden;
+  text-overflow: ellipsis;
+  white-space: nowrap;
+}
+
+// CSS image replacement
+// Source: https://github.com/h5bp/html5-boilerplate/commit/aa0396eae757
+@mixin hide-text() {
+  font: #{"0/0"} a;
+  color: transparent;
+  text-shadow: none;
+  background-color: transparent;
+  border: 0;
+}
+
+
+
+// CSS3 PROPERTIES
+// --------------------------------------------------
+
+// Single side border-radius
+@mixin border-top-radius($radius) {
+  border-top-right-radius: $radius;
+   border-top-left-radius: $radius;
+}
+@mixin border-right-radius($radius) {
+  border-bottom-right-radius: $radius;
+     border-top-right-radius: $radius;
+}
+@mixin border-bottom-radius($radius) {
+  border-bottom-right-radius: $radius;
+   border-bottom-left-radius: $radius;
+}
+@mixin border-left-radius($radius) {
+  border-bottom-left-radius: $radius;
+     border-top-left-radius: $radius;
+}
+
+// Drop shadows
+@mixin box-shadow($shadow) {
+  -webkit-box-shadow: $shadow; // iOS <4.3 & Android <4.1
+          box-shadow: $shadow;
+}
+
+// Transitions
+@mixin transition($transition) {
+  -webkit-transition: $transition;
+          transition: $transition;
+}
+@mixin transition-delay($transition-delay) {
+  -webkit-transition-delay: $transition-delay;
+          transition-delay: $transition-delay;
+}
+@mixin transition-duration($transition-duration) {
+  -webkit-transition-duration: $transition-duration;
+          transition-duration: $transition-duration;
+}
+@mixin transition-transform($transition) {
+  -webkit-transition: -webkit-transform $transition;
+     -moz-transition: -moz-transform $transition;
+       -o-transition: -o-transform $transition;
+          transition: transform $transition;
+}
+
+// Transformations
+@mixin transform($transform...) {
+    -webkit-transform: $transform;
+        -ms-transform: $transform;
+            transform: $transform;
+}
+
+@mixin rotate($degrees) {
+  -webkit-transform: rotate($degrees);
+      -ms-transform: rotate($degrees); // IE9+
+          transform: rotate($degrees);
+}
+
+@mixin scale($ratio) {
+  -webkit-transform: scale($ratio);
+      -ms-transform: scale($ratio); // IE9+
+          transform: scale($ratio);
+}
+
+@mixin translate($x, $y) {
+  -webkit-transform: translate($x, $y);
+      -ms-transform: translate($x, $y); // IE9+
+          transform: translate($x, $y);
+}
+@mixin skew($x, $y) {
+  -webkit-transform: skew($x, $y);
+      -ms-transform: skewX($x) skewY($y); // See https://github.com/twbs/bootstrap/issues/4885; IE9+
+          transform: skew($x, $y);
+}
+@mixin translate3d($x, $y, $z) {
+  -webkit-transform: translate3d($x, $y, $z);
+          transform: translate3d($x, $y, $z);
+}
+//transform origin
+@mixin transform-origin ($origin) {
+    moz-transform-origin: $origin;
+	     -o-transform-origin: $origin;
+	    -ms-transform-origin: $origin;
+	-webkit-transform-origin: $origin;
+          transform-origin: $origin;
+}
+
+// Backface visibility
+// Prevent browsers from flickering when using CSS 3D transforms.
+// Default value is `visible`, but can be changed to `hidden`
+// See git pull https://github.com/dannykeane/bootstrap.git backface-visibility for examples
+@mixin backface-visibility($visibility) {
+  -webkit-backface-visibility: $visibility;
+     -moz-backface-visibility: $visibility;
+          backface-visibility: $visibility;
+}
+
+// Box sizing
+@mixin box-sizing($boxmodel) {
+  -webkit-box-sizing: $boxmodel;
+     -moz-box-sizing: $boxmodel;
+          box-sizing: $boxmodel;
+}
+
+// User select
+// For selecting text on the page
+@mixin user-select($select) {
+  -webkit-user-select: $select;
+     -moz-user-select: $select;
+      -ms-user-select: $select; // IE10+
+       -o-user-select: $select;
+          user-select: $select;
+}
+
+// Resize anything
+@mixin resizable($direction) {
+  resize: $direction; // Options: horizontal, vertical, both
+  overflow: auto; // Safari fix
+}
+
+// CSS3 Content Columns
+@mixin content-columns($column-count, $column-gap: $grid-gutter-width) {
+  -webkit-column-count: $column-count;
+     -moz-column-count: $column-count;
+          column-count: $column-count;
+  -webkit-column-gap: $column-gap;
+     -moz-column-gap: $column-gap;
+          column-gap: $column-gap;
+}
+
+// Optional hyphenation
+@mixin hyphens($mode: auto) {
+  word-wrap: break-word;
+  -webkit-hyphens: $mode;
+     -moz-hyphens: $mode;
+      -ms-hyphens: $mode; // IE10+
+       -o-hyphens: $mode;
+          hyphens: $mode;
+}
+
+// Opacity
+@mixin opacity($opacity) {
+  opacity: $opacity;
+  // IE8 filter
+  $opacity-ie: ($opacity * 100);
+  filter: #{"alpha(opacity=#{opacity-ie})"};
+}
+
+
+
+// GRADIENTS
+// --------------------------------------------------
+
+#gradient {
+
+  // Horizontal gradient, from left to right
+  //
+  // Creates two color stops, start and end, by specifying a color and position for each color stop.
+  // Color stops are not available in IE9 and below.
+  @mixin horizontal($start-color: #555, $end-color: #333, $start-percent: 0%, $end-percent: 100%) {
+    background-image: -webkit-gradient(linear, $start-percent top, $end-percent top, from($start-color), to($end-color)); // Safari 4+, Chrome 2+
+    background-image: -webkit-linear-gradient(left, color-stop($start-color $start-percent), color-stop($end-color $end-percent)); // Safari 5.1+, Chrome 10+
+    background-image: -moz-linear-gradient(left, $start-color $start-percent, $end-color $end-percent); // FF 3.6+
+    background-image:  linear-gradient(to right, $start-color $start-percent, $end-color $end-percent); // Standard, IE10
+    background-repeat: repeat-x;
+    filter: progid:DXImageTransform.Microsoft.gradient(startColorstr='#{argb($start-color)}', endColorstr='#{argb($end-color)}', GradientType=1); // IE9 and down
+  }
+
+  // Vertical gradient, from top to bottom
+  //
+  // Creates two color stops, start and end, by specifying a color and position for each color stop.
+  // Color stops are not available in IE9 and below.
+  @mixin vertical($start-color: #555, $end-color: #333, $start-percent: 0%, $end-percent: 100%) {
+    background-image: -webkit-gradient(linear, left $start-percent, left $end-percent, from($start-color), to($end-color)); // Safari 4+, Chrome 2+
+    background-image: -webkit-linear-gradient(top, $start-color, $start-percent, $end-color, $end-percent); // Safari 5.1+, Chrome 10+
+    background-image:  -moz-linear-gradient(top, $start-color $start-percent, $end-color $end-percent); // FF 3.6+
+    background-image: linear-gradient(to bottom, $start-color $start-percent, $end-color $end-percent); // Standard, IE10
+    background-repeat: repeat-x;
+    filter: progid:DXImageTransform.Microsoft.gradient(startColorstr='#{argb($start-color)}', endColorstr='#{argb($end-color)}', GradientType=0); // IE9 and down
+  }
+
+  @mixin directional($start-color: #555, $end-color: #333, $deg: 45deg) {
+    background-repeat: repeat-x;
+    background-image: -webkit-linear-gradient($deg, $start-color, $end-color); // Safari 5.1+, Chrome 10+
+    background-image: -moz-linear-gradient($deg, $start-color, $end-color); // FF 3.6+
+    background-image: linear-gradient($deg, $start-color, $end-color); // Standard, IE10
+  }
+  @mixin horizontal-three-colors($start-color: #00b3ee, $mid-color: #7a43b6, $color-stop: 50%, $end-color: #c3325f) {
+    background-image: -webkit-gradient(left, linear, 0 0, 0 100%, from($start-color), color-stop($color-stop, $mid-color), to($end-color));
+    background-image: -webkit-linear-gradient(left, $start-color, $mid-color $color-stop, $end-color);
+    background-image: -moz-linear-gradient(left, $start-color, $mid-color $color-stop, $end-color);
+    background-image: linear-gradient(to right, $start-color, $mid-color $color-stop, $end-color);
+    background-repeat: no-repeat;
+    filter: progid:DXImageTransform.Microsoft.gradient(startColorstr='#{argb($start-color)}', endColorstr='#{argb($end-color)}', GradientType=1); // IE9 and down
+  }
+  @mixin vertical-three-colors($start-color: #00b3ee, $mid-color: #7a43b6, $color-stop: 50%, $end-color: #c3325f) {
+    background-image: -webkit-gradient(linear, 0 0, 0 100%, from($start-color), color-stop($color-stop, $mid-color), to($end-color));
+    background-image: -webkit-linear-gradient($start-color, $mid-color $color-stop, $end-color);
+    background-image: -moz-linear-gradient(top, $start-color, $mid-color $color-stop, $end-color);
+    background-image: linear-gradient($start-color, $mid-color $color-stop, $end-color);
+    background-repeat: no-repeat;
+    filter: progid:DXImageTransform.Microsoft.gradient(startColorstr='#{argb($start-color)}', endColorstr='#{argb($end-color)}', GradientType=0); // IE9 and down
+  }
+  @mixin radial($inner-color: #555, $outer-color: #333) {
+    background-image: -webkit-gradient(radial, center center, 0, center center, 460, from($inner-color), to($outer-color));
+    background-image: -webkit-radial-gradient(circle, $inner-color, $outer-color);
+    background-image: -moz-radial-gradient(circle, $inner-color, $outer-color);
+    background-image: radial-gradient(circle, $inner-color, $outer-color);
+    background-repeat: no-repeat;
+  }
+  @mixin striped($color: #555, $angle: 45deg) {
+    background-image: -webkit-gradient(linear, 0 100%, 100% 0, color-stop(.25, rgba(255,255,255,.15)), color-stop(.25, transparent), color-stop(.5, transparent), color-stop(.5, rgba(255,255,255,.15)), color-stop(.75, rgba(255,255,255,.15)), color-stop(.75, transparent), to(transparent));
+    background-image: -webkit-linear-gradient($angle, rgba(255,255,255,.15) 25%, transparent 25%, transparent 50%, rgba(255,255,255,.15) 50%, rgba(255,255,255,.15) 75%, transparent 75%, transparent);
+    background-image: -moz-linear-gradient($angle, rgba(255,255,255,.15) 25%, transparent 25%, transparent 50%, rgba(255,255,255,.15) 50%, rgba(255,255,255,.15) 75%, transparent 75%, transparent);
+    background-image: linear-gradient($angle, rgba(255,255,255,.15) 25%, transparent 25%, transparent 50%, rgba(255,255,255,.15) 50%, rgba(255,255,255,.15) 75%, transparent 75%, transparent);
+  }
+}
+
+// Reset filters for IE
+//
+// When you need to remove a gradient background, do not forget to use this to reset
+// the IE filter for IE9 and below.
+@mixin reset-filter() {
+  filter: progid:DXImageTransform.Microsoft.gradient(enabled = false);
+}
+
+
+
+// Retina images
+//
+// Short retina mixin for setting background-image and -size
+
+@mixin img-retina($file-1x, $file-2x, $width-1x, $height-1x) {
+  background-image: image-url("#{$file-1x}");
+  background-size: $width-1x $height-1x;
+
+  @media
+  only screen and (-webkit-min-device-pixel-ratio: 2),
+  only screen and (   min--moz-device-pixel-ratio: 2),
+  only screen and (     -o-min-device-pixel-ratio: 2/1),
+  only screen and (        min-device-pixel-ratio: 2),
+  only screen and (                min-resolution: 192dpi),
+  only screen and (                min-resolution: 2dppx) {
+    background-image: image-url("#{$file-2x}");
+    background-size: $width-1x $height-1x;
+  }
+}
+
+
+// Responsive image
+//
+// Keep images from scaling beyond the width of their parents.
+
+@mixin img-responsive($display: block) {
+  display: $display;
+  max-width: 100%; // Part 1: Set a maximum relative to the parent
+  height: auto; // Part 2: Scale the height according to the width, otherwise you get stretching
+}
+
+
+// COMPONENT MIXINS
+// --------------------------------------------------
+
+// Horizontal dividers
+// -------------------------
+// Dividers (basically an hr) within dropdowns and nav lists
+@mixin nav-divider($color: #e5e5e5) {
+  height: 1px;
+  margin: (($line-height-computed / 2) - 1) 0;
+  overflow: hidden;
+  background-color: $color;
+}
+
+// Panels
+// -------------------------
+@mixin panel-variant($border, $heading-text-color, $heading-bg-color, $heading-border) {
+  border-color: $border;
+  & > .panel-heading {
+    color: $heading-text-color;
+    background-color: $heading-bg-color;
+    border-color: $heading-border;
+    + .panel-collapse .panel-body {
+      border-top-color: $border;
+    }
+  }
+  & > .panel-footer {
+    + .panel-collapse .panel-body {
+      border-bottom-color: $border;
+    }
+  }
+}
+
+// Alerts
+// -------------------------
+@mixin alert-variant($background, $border, $text-color) {
+  background-color: $background;
+  border-color: $border;
+  color: $text-color;
+  hr {
+    border-top-color: darken($border, 5%);
+  }
+  .alert-link {
+    color: darken($text-color, 10%);
+  }
+}
+
+// Tables
+// -------------------------
+@mixin table-row-variant($state, $background, $border) {
+  // Exact selectors below required to override `.table-striped` and prevent
+  // inheritance to nested tables.
+  .table > thead > tr,
+  .table > tbody > tr,
+  .table > tfoot > tr {
+    > td.#{state},
+    > th.#{state},
+    &.#{state} > td,
+    &.#{state} > th {
+      background-color: $background;
+      border-color: $border;
+    }
+  }
+
+  // Hover states for `.table-hover`
+  // Note: this is not available for cells or rows within `thead` or `tfoot`.
+  .table-hover > tbody > tr {
+    > td.#{state}:hover,
+    > th.#{state}:hover,
+    &.#{state}:hover > td {
+      background-color: darken($background, 5%);
+      border-color: darken($border, 5%);
+    }
+  }
+}
+
+// Button variants
+// -------------------------
+// Easily pump out default styles, as well as :hover, :focus, :active,
+// and disabled options for all buttons
+@mixin button-variant($color, $background, $border) {
+  color: $color;
+  background-color: $background;
+  border-color: $border;
+
+  &:hover,
+  &:focus,
+  &:active,
+  &.active,
+  .open .dropdown-toggle& {
+    color: $color;
+    background-color: darken($background, 8%);
+        border-color: darken($border, 12%);
+  }
+  &:active,
+  &.active,
+  .open .dropdown-toggle& {
+    background-image: none;
+  }
+  &.disabled,
+  &[disabled],
+  fieldset[disabled] & {
+    &,
+    &:hover,
+    &:focus,
+    &:active,
+    &.active {
+      background-color: $background;
+          border-color: $border
+    }
+  }
+}
+
+// Button sizes
+// -------------------------
+@mixin button-size($padding-vertical, $padding-horizontal, $font-size, $line-height, $border-radius) {
+  padding: $padding-vertical $padding-horizontal;
+  font-size: $font-size;
+  line-height: $line-height;
+  border-radius: $border-radius;
+}
+
+// Pagination
+// -------------------------
+@mixin pagination-size($padding-vertical, $padding-horizontal, $font-size, $border-radius) {
+  > li {
+    > a,
+    > span {
+      padding: $padding-vertical $padding-horizontal;
+      font-size: $font-size;
+    }
+    &:first-child {
+      > a,
+      > span {
+        @include border-left-radius($border-radius);
+      }
+    }
+    &:last-child {
+      > a,
+      > span {
+        @include border-right-radius($border-radius);
+      }
+    }
+  }
+}
+
+// Labels
+// -------------------------
+@mixin label-variant($color) {
+  background-color: $color;
+  &[href] {
+    &:hover,
+    &:focus {
+      background-color: darken($color, 10%);
+    }
+  }
+}
+
+// Navbar vertical align
+// -------------------------
+// Vertically center elements in the navbar.
+// Example: an element has a height of 30px, so write out `@include navbar-vertical-align(30px);` to calculate the appropriate top margin.
+@mixin navbar-vertical-align($element-height) {
+  margin-top: (($navbar-height - $element-height) / 2);
+  margin-bottom: (($navbar-height - $element-height) / 2);
+}
+
+// Progress bars
+// -------------------------
+// @mixin progress-bar-variant($color) {
+//   background-color: $color;
+//   .progress-striped & {
+//     #gradient > @include striped($color);
+//   }
+// }
+
+// Responsive utilities
+// -------------------------
+// More easily include all the states for responsive-utilities.less.
+@mixin responsive-visibility() {
+  display: block !important;
+  tr& { display: table-row !important; }
+  th&,
+  td& { display: table-cell !important; }
+}
+
+@mixin responsive-invisibility() {
+  display: none !important;
+  tr& { display: none !important; }
+  th&,
+  td& { display: none !important; }
+}
+
+// Grid System
+// -----------
+
+// Centered container element
+@mixin container-fixed() {
+  margin-right: auto;
+  margin-left: auto;
+  padding-left:  ($grid-gutter-width / 2);
+  padding-right: ($grid-gutter-width / 2);
+  @include clearfix();
+}
+
+// Creates a wrapper for a series of columns
+@mixin make-row($gutter: $grid-gutter-width) {
+  margin-left:  ($gutter / -2);
+  margin-right: ($gutter / -2);
+  @include clearfix();
+}
+
+// Generate the extra small columns
+@mixin make-xs-column($columns, $gutter: $grid-gutter-width) {
+  position: relative;
+  float: left;
+  width: percentage(($columns / $grid-columns));
+  // Prevent columns from collapsing when empty
+  min-height: 1px;
+  // Inner gutter via padding
+  padding-left:  ($gutter / 2);
+  padding-right: ($gutter / 2);
+}
+
+// Generate the small columns
+@mixin make-sm-column($columns, $gutter: $grid-gutter-width) {
+  position: relative;
+  // Prevent columns from collapsing when empty
+  min-height: 1px;
+  // Inner gutter via padding
+  padding-left:  ($gutter / 2);
+  padding-right: ($gutter / 2);
+
+  // Calculate width based on number of columns available
+  @media (min-width: $screen-sm) {
+    float: left;
+    width: percentage(($columns / $grid-columns));
+  }
+}
+
+// Generate the small column offsets
+@mixin make-sm-column-offset($columns) {
+  @media (min-width: $screen-sm) {
+    margin-left: percentage(($columns / $grid-columns));
+  }
+}
+@mixin make-sm-column-push($columns) {
+  @media (min-width: $screen-sm) {
+    left: percentage(($columns / $grid-columns));
+  }
+}
+@mixin make-sm-column-pull($columns) {
+  @media (min-width: $screen-sm) {
+    right: percentage(($columns / $grid-columns));
+  }
+}
+
+// Generate the medium columns
+@mixin make-md-column($columns, $gutter: $grid-gutter-width) {
+  position: relative;
+  // Prevent columns from collapsing when empty
+  min-height: 1px;
+  // Inner gutter via padding
+  padding-left:  ($gutter / 2);
+  padding-right: ($gutter / 2);
+
+  // Calculate width based on number of columns available
+  @media (min-width: $screen-md) {
+    float: left;
+    width: percentage(($columns / $grid-columns));
+  }
+}
+
+// Generate the large column offsets
+@mixin make-md-column-offset($columns) {
+  @media (min-width: $screen-md) {
+    margin-left: percentage(($columns / $grid-columns));
+  }
+}
+@mixin make-md-column-push($columns) {
+  @media (min-width: $screen-md) {
+    left: percentage(($columns / $grid-columns));
+  }
+}
+@mixin make-md-column-pull($columns) {
+  @media (min-width: $screen-md) {
+    right: percentage(($columns / $grid-columns));
+  }
+}
+
+// Generate the large columns
+@mixin make-lg-column($columns, $gutter: $grid-gutter-width) {
+  position: relative;
+  // Prevent columns from collapsing when empty
+  min-height: 1px;
+  // Inner gutter via padding
+  padding-left:  ($gutter / 2);
+  padding-right: ($gutter / 2);
+
+  // Calculate width based on number of columns available
+  @media (min-width: $screen-lg) {
+    float: left;
+    width: percentage(($columns / $grid-columns));
+  }
+}
+
+// Generate the large column offsets
+@mixin make-lg-column-offset($columns) {
+  @media (min-width: $screen-lg) {
+    margin-left: percentage(($columns / $grid-columns));
+  }
+}
+@mixin make-lg-column-push($columns) {
+  @media (min-width: $screen-lg) {
+    left: percentage(($columns / $grid-columns));
+  }
+}
+@mixin make-lg-column-pull($columns) {
+  @media (min-width: $screen-lg) {
+    right: percentage(($columns / $grid-columns));
+  }
+}
+
+
+// Form validation states
+//
+// Used in forms.less to generate the form validation CSS for warnings, errors,
+// and successes.
+
+@mixin form-control-validation($text-color: #555, $border-color: #ccc, $background-color: #f5f5f5) {
+  // Color the label and help text
+  .help-block,
+  .control-label {
+    color: $text-color;
+  }
+  // Set the border and box shadow on specific inputs to match
+  .form-control {
+    border-color: $border-color;
+    @include box-shadow(inset 0 1px 1px rgba(0,0,0,.075)); // Redeclare so transitions work
+    &:focus {
+      border-color: darken($border-color, 10%);
+      $shadow: inset 0 1px 1px rgba(0,0,0,.075), 0 0 6px lighten($border-color, 20%);
+      @include box-shadow($shadow);
+    }
+  }
+  // Set validation states also for addons
+  .input-group-addon {
+    color: $text-color;
+    border-color: $border-color;
+    background-color: $background-color;
+  }
+}
+
+// Form control focus state
+//
+// Generate a customized focus state and for any input with the specified color,
+// which defaults to the `$input-focus-border` variable.
+//
+// We highly encourage you to not customize the default value, but instead use
+// this to tweak colors on an as-needed basis. This aesthetic change is based on
+// WebKit's default styles, but applicable to a wider range of browsers. Its
+// usability and accessibility should be taken into account with any change.
+//
+// Example usage: change the default blue border and shadow to white for better
+// contrast against a dark gray background.
+
+@mixin form-control-focus($color: $input-border-focus) {
+  $color-rgba: rgba(red($color), green($color), blue($color), .6);
+  &:focus {
+    border-color: $color;
+    outline: 0;
+    @include box-shadow(#{"inset 0 1px 1px rgba(0,0,0,.075), 0 0 8px #{color-rgba}"});
+  }
+}
+
+// Form control sizing
+//
+// Relative text size, padding, and border-radii changes for form controls. For
+// horizontal sizing, wrap controls in the predefined grid classes. `<select>`
+// element gets special love because it's special, and that's a fact!
+
+@mixin input-size($input-height, $padding-vertical, $padding-horizontal, $font-size, $line-height, $border-radius) {
+  height: $input-height;
+  padding: $padding-vertical $padding-horizontal;
+  font-size: $font-size;
+  line-height: $line-height;
+  border-radius: $border-radius;
+
+  select& {
+    height: $input-height;
+    line-height: $input-height;
+  }
+
+  textarea& {
+    height: auto;
+  }
+}
+
+
+//mixins
+@mixin img-retina($image1x, $image, $width, $height) {
+  background-image: url($image1x);
+  background-size: $width $height;
+  background-repeat: no-repeat;
+
+  @media (min--moz-device-pixel-ratio: 1.3),
+         (-o-min-device-pixel-ratio: 2.6/2),
+         (-webkit-min-device-pixel-ratio: 1.3),
+         (min-device-pixel-ratio: 1.3),
+         (min-resolution: 1.3dppx) {
+    /* on retina, use image that's scaled by 2 */
+    background-image: url($image);
+    background-size: $width $height;
+  }
+}
+
+@mixin btn-shadow{
+  box-shadow: 2px 3px 2px rgba(0,0,0,0.08);
+}
diff --git a/website/source/assets/stylesheets/_sidebar.scss b/website/source/assets/stylesheets/_sidebar.scss
new file mode 100644
index 000000000..1f6a94db0
--- /dev/null
+++ b/website/source/assets/stylesheets/_sidebar.scss
@@ -0,0 +1,474 @@
+
+// Base variables
+// --------------------------------------------------
+$screen-tablet:          768px;
+
+$gray-darker:            #212121; // #212121 - text
+$gray-secondary:              #757575; // #757575 - secondary text, icons
+$gray:                   #bdbdbd; // #bdbdbd - hint text
+$gray-light:             #e0e0e0; // #e0e0e0 - divider
+$gray-lighter:           #f5f5f5; // #f5f5f5 - background
+
+/* -- Sidebar style ------------------------------- */
+
+// Sidebar variables
+// --------------------------------------------------
+$zindex-sidebar-fixed: 1035;
+
+$sidebar-desktop-width: 280px;
+$sidebar-width: 240px;
+
+
+$sidebar-padding: 16px;
+$sidebar-divider: $sidebar-padding/2;
+
+$sidebar-nav-height: 48px;
+
+$sidebar-icon-width: 40px;
+$sidebar-icon-height: 20px;
+
+$sidebar-badge-size: $sidebar-nav-height/2;
+$sidebar-badge-font-size: 10px;
+
+$sidebar-brand-color: $gray-secondary;
+$sidebar-icon-color: $gray-secondary;
+$sidebar-menu-color: $gray-darker;
+
+
+$sidebar-font-weight: 300;
+
+// Sidebar mixins
+// --------------------------------------------------
+
+// Sidebar horizontal block
+//
+// This settings will extended by .sidebar-text, .sidebar-brand and .sidebar-nav>li>a
+@mixin sidebar-block()
+{
+  display: block;
+  line-height: $sidebar-nav-height;
+  padding: 0;
+  //padding-left: ($sidebar-padding + $sidebar-badge-size) + $sidebar-padding;
+  //padding-right: ($sidebar-padding + $sidebar-badge-size) + $sidebar-padding;
+  text-decoration: none;
+  clear: both;
+  @include v-nav-style-core();
+  //@include text-overflow();
+  @include transition(all .2s ease-in-out);
+  color: $blue-dark;
+
+  &:hover, &:focus {
+    @include box-shadow(none);
+    outline: none;
+  }
+
+  // positioning caret in sidebar block
+  .caret {
+    position: absolute;
+    right: $sidebar-padding + $sidebar-badge-size/2 - 4px; // caret centered by badge position; 4px - caret width
+    top: $sidebar-nav-height/2;
+  }
+  // positioning badge in sidebar block
+  .sidebar-badge {
+    position: absolute;
+    right: $sidebar-padding;
+    top: ($sidebar-nav-height - $sidebar-badge-size)/2 ;
+  }
+}
+
+// Sidebar design template
+//
+// You can make own sidebar style with this template
+@mixin sidebar-template(
+  $color,
+  $bg,
+  $header-bg,
+  $brand-color,
+  $brand-bg,
+  $brand-hover-color,
+  $brand-hover-bg,
+  $divider,
+  $badge-color,
+  $badge-bg,
+  $icon-color,
+  $icon-hover-color,
+  $link-color,
+  $link-bg,
+  $link-hover-color,
+  $link-hover-bg,
+  $link-active-color,
+  $link-active-bg,
+  $link-disabled-color,
+  $link-disabled-bg
+) {
+
+  background-color: $bg;
+
+  ul{
+    padding-left: 0;
+    list-style-type: none;
+  }
+
+  .sidebar-header {
+    background-color: $header-bg;
+    margin-bottom: 15px;
+  }
+
+  .sidebar-divider, .sidebar-nav .divider {
+    background-color: $divider;
+  }
+
+  .sidebar-text {
+    color: $color;
+  }
+
+  .buttons-nav{
+    margin-top: 10px;
+    text-align: center;
+    @include v-nav-style-core();
+
+    li{
+        margin-bottom: 20px;
+        a{
+            min-width: 148px;
+            color: $blue-dark;
+            &:hover{
+                color: $green-dark;
+            }
+        }
+    }
+  }
+
+  .sidebar-nav {
+    text-align: center;
+    //border-bottom: 1px solid $faint-gray;
+    padding-bottom: 8px;
+
+    &:last-child{
+      border-bottom: none;
+    }
+
+    li > a {
+      color: $link-color;
+      background-color: $link-bg;
+
+      i {
+        color: $icon-color;
+      }
+    }
+    li:hover > a, li > a:hover {
+      color: $link-hover-color;
+      background-color: $link-hover-bg;
+
+      i {
+        color: $icon-hover-color;
+      }
+    }
+    li:focus > a, li > a:focus {
+      color: $link-color;
+      background-color: $link-bg;
+
+      i {
+        color: $icon-hover-color;
+      }
+    }
+
+    > .open > a {
+      &,
+      &:hover,
+      &:focus {
+        color: $link-hover-color;
+        background-color: $link-hover-bg;
+      }
+    }
+
+    > .active > a {
+      &,
+      &:hover,
+      &:focus {
+        color: $link-active-color;
+        background-color: $link-active-bg;
+      }
+    }
+    > .disabled > a {
+      &,
+      &:hover,
+      &:focus {
+        color: $link-disabled-color;
+        background-color: $link-disabled-bg;
+      }
+    }
+    > li > .ink {
+      //background: #80d8ff;
+      //opacity: 0.5;
+    }
+
+    // Dropdown menu items
+    > .dropdown {
+      // Remove background color from open dropdown
+      > .dropdown-menu {
+
+        background-color: $link-hover-bg;
+
+        > li > a {
+          &:focus {
+            background-color: $link-hover-bg;
+            color: $link-hover-color;
+          }
+          &:hover {
+            background-color: darken($link-hover-bg, 7%);
+            color: $link-hover-color;
+          }
+        }
+
+        > .active > a {
+          &,
+          &:hover,
+          &:focus {
+            color: $link-active-color;
+            background-color: $link-active-bg;
+          }
+        }
+      }
+    }
+  }
+}
+
+//
+// Sidebars
+// --------------------------------------------------
+
+// Wrapper and base class
+//
+// Provide a static sidebar from which we expand to create other sidebar variations.
+.sidebar {
+  position: relative;
+  display: block;
+  min-height: 100%;
+  overflow-y: auto;
+  overflow-x: hidden;
+  border: none;
+  @include transition(all 0.5s cubic-bezier(0.55, 0, 0.1, 1));
+  @include clearfix();
+}
+
+// Sidebar Elements
+//
+// Basic style of sidebar elements
+.sidebar {
+
+  // Sidebar heading
+  //----------------
+  .sidebar-header {
+    position: relative;
+    margin-bottom: $sidebar-divider;
+    @include transition(all .2s ease-in-out);
+    //border-bottom: 1px solid $faint-gray;
+
+    .buttons{
+      text-align: center;
+      padding: $xsmall-pad 0 $small-pad;
+      a{
+        &.outline-btn{
+          margin-right: 10px;
+        }
+      }
+    }
+  }
+
+ .sidebar-image {
+    padding-top: 24px;
+    img {
+      display: block;
+      margin: 0 auto;
+    }
+  }
+
+  // Brand/project name
+  //
+  // In google guideline used for email dropdown
+  .sidebar-brand {
+    position: absolute;
+    bottom: 0;
+    left: 0;
+    right: 0;
+    @include sidebar-block();
+
+    &:hover,
+    &:focus {
+      text-decoration: none;
+    }
+  }
+
+  // Sidebar text
+  //----------------
+  .sidebar-text {
+    @include sidebar-block();
+  }
+
+  // Sidebar icons
+  //----------------
+  .sidebar-icon {
+    display: inline-block;
+    height: $sidebar-icon-height;
+    margin-right: $sidebar-divider;
+    text-align: left;
+    font-size: $sidebar-icon-height;
+    vertical-align: middle;
+
+    &:before, &:after {
+      vertical-align: middle;
+    }
+  }
+}
+
+
+
+// Sidebar navigation class
+// ------------------------
+.sidebar .sidebar-nav {
+  margin: 0;
+  padding: 0;
+
+  // Links
+  //----------------
+  li {
+    position: relative;
+    list-style-type: none;
+
+    a {
+      position: relative;
+      cursor: pointer;
+      user-select: none;
+      @include sidebar-block();
+
+      &:hover {
+        background: transparent;
+      }
+    }
+  }
+}
+
+// Sidebar color theme variations
+//
+// ------------------------
+.sidebar-default {
+  @include sidebar-template(
+  $color: $gray-darker,
+  $bg: #fff,
+  $header-bg: $white,
+  $brand-color: $gray-dark,
+  $brand-bg: transparent,
+  $brand-hover-color: $gray-darker,
+  $brand-hover-bg: rgba(0, 0, 0, 0.10),
+  $divider: $gray,
+  $badge-color: #fff,
+  $badge-bg: $gray,
+  $icon-color: $gray-dark,
+  $icon-hover-color: $gray-dark,
+  $link-color: $gray-darker,
+  $link-bg: transparent,
+  $link-hover-color: $gray-darker,
+  $link-hover-bg: lighten($faint-gray, 6%),
+  $link-active-color: $gray-darker,
+  $link-active-bg: $gray-light,
+  $link-disabled-color: $gray-light,
+  $link-disabled-bg: transparent
+  );
+}
+
+
+// Sidebar toggling
+//
+// Hide sidebar
+.sidebar {
+  width: 0;
+  @include translate3d(-$sidebar-desktop-width, 0, 0);
+
+  &.open {
+    min-width: $sidebar-desktop-width;
+    width: $sidebar-desktop-width;
+    @include translate3d(0, 0, 0);
+  }
+}
+
+// Sidebar positions: fix the left/right sidebars
+.sidebar-fixed-left,
+.sidebar-fixed-right,
+.sidebar-stacked {
+  position: fixed;
+  top: 0;
+  bottom: 0;
+  z-index: $zindex-sidebar-fixed;
+}
+.sidebar-stacked {
+  left: 0;
+}
+.sidebar-fixed-left {
+  left: 0;
+  box-shadow: 2px 0px 25px rgba(0,0,0,0.15);
+  -webkit-box-shadow: 2px 0px 25px rgba(0,0,0,0.15);
+}
+.sidebar-fixed-right {
+  right: 0;
+  box-shadow: 0px 2px 25px rgba(0,0,0,0.15);
+  -webkit-box-shadow: 0px 2px 25px rgba(0,0,0,0.15);
+
+  @include translate3d($sidebar-desktop-width, 0, 0);
+  &.open {
+    @include translate3d(0, 0, 0);
+  }
+  .icon-material-sidebar-arrow:before {
+    content: "\e614"; // icon-material-arrow-forward
+  }
+}
+
+// Sidebar size
+//
+// Change size of sidebar and sidebar elements on small screens
+@media (max-width: $screen-tablet) {
+  .sidebar.open {
+    min-width: $sidebar-width;
+    width: $sidebar-width;
+  }
+
+  .sidebar .sidebar-header {
+    //height: $sidebar-width * 9/16; // 16:9 header dimension
+  }
+
+  .sidebar .sidebar-image {
+    /* img {
+      width: $sidebar-width/4 - $sidebar-padding;
+      height: $sidebar-width/4 - $sidebar-padding;
+    } */
+  }
+}
+
+.sidebar-overlay {
+  visibility: hidden;
+  position: fixed;
+  top: 0;
+  left: 0;
+  right: 0;
+  bottom: 0;
+  opacity: 0;
+  background: $white;
+  z-index: $zindex-sidebar-fixed - 1;
+
+  -webkit-transition: visibility 0 linear .4s,opacity .4s cubic-bezier(.4,0,.2,1);
+  -moz-transition: visibility 0 linear .4s,opacity .4s cubic-bezier(.4,0,.2,1);
+  transition: visibility 0 linear .4s,opacity .4s cubic-bezier(.4,0,.2,1);
+  -webkit-transform: translateZ(0);
+  -moz-transform: translateZ(0);
+  -ms-transform: translateZ(0);
+  -o-transform: translateZ(0);
+  transform: translateZ(0);
+}
+
+.sidebar-overlay.active {
+  opacity: 0.3;
+  visibility: visible;
+  -webkit-transition-delay: 0;
+  -moz-transition-delay: 0;
+  transition-delay: 0;
+}
diff --git a/website/source/assets/stylesheets/_utilities.scss b/website/source/assets/stylesheets/_utilities.scss
new file mode 100755
index 000000000..a1543f039
--- /dev/null
+++ b/website/source/assets/stylesheets/_utilities.scss
@@ -0,0 +1,210 @@
+//
+// Utility classes
+// --------------------------------------------------
+
+
+//
+// -------------------------
+@mixin anti-alias() {
+    text-rendering: optimizeLegibility;
+    -webkit-font-smoothing: antialiased;
+}
+
+@mixin open-light() {
+    font-family: $font-family-open-sans;
+    font-weight: 300;
+}
+
+@mixin open() {
+    font-family: $font-family-open-sans;
+    font-weight: 400;
+}
+
+@mixin open-sb() {
+    font-family: $font-family-open-sans;
+    font-weight: 600;
+}
+
+@mixin open-bold() {
+    font-family: $font-family-open-sans;
+    font-weight: 700;
+}
+
+@mixin skewY($skew) {
+    -webkit-transform: skewY($skew);
+    -moz-transform: skewY($skew);
+    -ms-transform: skewY($skew);
+    -o-transform: skewY($skew);
+    transform: skewY($skew);
+}
+
+@mixin v-nav-style-core{
+    color: $gray-darker;
+    font-family: $font-family-blanc-reg;
+    font-size: 13px;
+    text-transform: uppercase;
+    letter-spacing: 0.0625em;
+}
+
+@mixin v-nav-style{
+    margin: 0 15px;
+    padding: 0;
+    line-height: 22px;
+    @include v-nav-style-core();
+    @include transition( color 0.3s ease );
+
+    &:hover{
+        color: $green-dark;
+        @include transition( color 0.3s ease );
+        background-color: transparent;
+    }
+}
+
+@mixin bez-1-transition{
+    @include transition( all 300ms ease-in-out );
+}
+
+
+@keyframes press {
+  0% {
+    opacity: 1;
+  }
+  50% {
+    opacity: .55
+  }
+  100% {
+    opacity: 1;
+  }
+}
+
+@-webkit-keyframes press {
+  0% {
+    opacity: 1;
+  }
+  50% {
+    opacity: .55
+  }
+  100% {
+    opacity: 1;
+  }
+}
+
+#demo-app .loading-bar{
+    display: block;
+    -webkit-animation: shift-rightwards 2s ease-in-out infinite;
+    -moz-animation: shift-rightwards 2s ease-in-out infinite;
+    -ms-animation: shift-rightwards 2s ease-in-out infinite;
+    -o-animation: shift-rightwards 2s ease-in-out infinite;
+    animation: shift-rightwards 2s ease-in-out infinite;
+    -webkit-animation-delay: .4s;
+    -moz-animation-delay: .4s;
+    -o-animation-delay: .4s;
+    animation-delay: .4s;
+}
+
+.loading-bar{
+    position: fixed;
+    display: none;
+    bottom: 0;
+    left: 0;
+    right: 0;
+    height: 2px;
+    z-index: 800;
+    background: $blue;
+    -webkit-transform: translateX(100%);
+    -moz-transform: translateX(100%);
+    -o-transform: translateX(100%);
+    transform: translateX(100%);
+}
+
+@-webkit-keyframes shift-rightwards
+{
+    0%
+    {
+        @include translate(-100%, 0);
+    }
+
+    40%
+    {
+        @include translate(0%, 0);
+    }
+
+    60%
+    {
+        @include translate(0%, 0);
+    }
+
+    100%
+    {
+        @include translate(100%, 0);
+    }
+
+}
+@-moz-keyframes shift-rightwards
+{
+    0%
+    {
+        @include translate(-100%, 0);
+    }
+
+    40%
+    {
+        @include translate(0%, 0);
+    }
+
+    60%
+    {
+        @include translate(0%, 0);
+    }
+
+    100%
+    {
+        @include translate(100%, 0);
+    }
+
+}
+@-o-keyframes shift-rightwards
+{
+    0%
+    {
+        @include translate(-100%, 0);
+    }
+
+    40%
+    {
+        @include translate(0%, 0);
+    }
+
+    60%
+    {
+        @include translate(0%, 0);
+    }
+
+    100%
+    {
+        @include translate(100%, 0);
+    }
+
+}
+@keyframes shift-rightwards
+{
+    0%
+    {
+        @include translate(-100%, 0);
+    }
+
+    40%
+    {
+        @include translate(0%, 0);
+    }
+
+    60%
+    {
+        @include translate(0%, 0);
+    }
+
+    100%
+    {
+        @include translate(100%, 0);
+    }
+}
diff --git a/website/source/assets/stylesheets/_variables.scss b/website/source/assets/stylesheets/_variables.scss
new file mode 100755
index 000000000..546424316
--- /dev/null
+++ b/website/source/assets/stylesheets/_variables.scss
@@ -0,0 +1,80 @@
+//
+// Variables
+// --------------------------------------------------
+
+
+// Global values
+// --------------------------------------------------
+
+$header-height:  		   	 90px;
+$btn-border-radius:   		 4px;
+$el-border-radius:   		 6px;
+// colors
+// -------------------------
+
+$white: 					#fff;
+$black:                 	#000;
+$gray:						#929199;
+$light-gray:				#C2C1C7;
+$faint-gray:				#E3E3EA;
+$green:                     #56cdad;
+$green-dark:                #449b82;
+$green-light:               #9bdb9c;
+$green-faint:               #E3F5E3;
+$blue-dark:					#4e5859;
+$blue-light:                #89999A;
+$blue:                  	#00BFE0;
+$blue-faint:                #E0E8E8;
+$light-black: 				#242424;
+$orange:               		#e78c5b;
+$gray-dark: 				#3B4142; //#4e5859;
+$gray: 						#777;
+$gray-light:   				#939393;
+$gray-lighter:   			#979797;
+$red: 						#dd4e58;
+$red-dark:           		#c5454e;
+$purple:   				    #822ff7;
+$light-purple:				#f7f3f9;
+$btn-color:  				#4592C5;
+
+
+// Scaffolding
+// -------------------------
+$body-bg:               	#fff;
+$text-color:            	$gray;
+
+// Links
+// -------------------------
+$link-color:            	$red-dark;
+$link-hover-color:      	darken($link-color, 15%);
+
+// Typography
+// -------------------------
+$font-family-open-sans:		'Open Sans', 'Helvetica Neue', Helvetica, Arial, sans-serif;
+$font-family-blanc: 	    'Blanc-Light', 'Lato', 'Helvetica Neue', Helvetica, Arial, sans-serif;
+$font-family-blanc-reg: 	'Blanc-Regular', 'Lato', 'Helvetica Neue', Helvetica, Arial, sans-serif;
+$font-weight-xl:  		    300;
+$font-weight-reg:  	        400;
+$font-weight-sb:            600;
+$font-weight-xb:  		    700;
+$font-size-xl:              44px;
+$font-size-l:               36px;
+$font-size-m:               28px;
+$font-size-reg:             16px;
+
+$text-shadow: 				1px 1px 1px #000;
+$shadow: 					$text-shadow;
+
+
+//margin + padding
+$xsmall-pad: 20px;
+$small-pad: 30px;
+$med-pad: 70px;
+$large-pad: 120px;
+$xl-pad: 150px;
+
+$light-outline: #f7f7f7;
+
+//
+$easeInOutBack: cubic-bezier(0.68, -0.55, 0.265, 1.55);
+$easeOutBack: cubic-bezier(0.175, 0.885, 0.32, 1.275);
diff --git a/website/source/assets/stylesheets/_webfonts.scss b/website/source/assets/stylesheets/_webfonts.scss
new file mode 100644
index 000000000..c2d75b370
--- /dev/null
+++ b/website/source/assets/stylesheets/_webfonts.scss
@@ -0,0 +1,29 @@
+/**
+ * @license
+ * MyFonts Webfont Build ID 3078913, 2015-08-21T01:21:30-0400
+ *
+ * The fonts listed in this notice are subject to the End User License
+ * Agreement(s) entered into by the website owner. All other parties are
+ * explicitly restricted from using the Licensed Webfonts(s).
+ *
+ * You may obtain a valid license at the URLs below.
+ *
+ * Webfont: Blanc-Light by Latinotype
+ * URL: http://www.myfonts.com/fonts/latinotype/blanc/light/
+ * Copyright: Jorge Cisterna
+ * Licensed pageviews: 10,000
+ *
+ *
+ * License: http://www.myfonts.com/viewlicense?type=web&buildid=3078913
+ *
+ * © 2015 MyFonts Inc
+*/
+
+
+/* @import must be at top of file, otherwise CSS will not work */
+//@import url("//hello.myfonts.net/count/2efc68");
+@import url("//hello.myfonts.net/count/2efb01");
+
+
+@font-face {font-family: 'Blanc-Light';src: url('../webfonts/2EFB01_0_0.eot');src: url('../webfonts/2EFB01_0_0.eot?#iefix') format('embedded-opentype'),url('../webfonts/2EFB01_0_0.woff2') format('woff2'),url('../webfonts/2EFB01_0_0.woff') format('woff'),url('../webfonts/2EFB01_0_0.ttf') format('truetype');}
+@font-face {font-family: 'Blanc-Regular';src: url('../webfonts/2EFC68_0_0.eot');src: url('../webfonts/2EFC68_0_0.eot?#iefix') format('embedded-opentype'),url('../webfonts/2EFC68_0_0.woff2') format('woff2'),url('../webfonts/2EFC68_0_0.woff') format('woff'),url('../webfonts/2EFC68_0_0.ttf') format('truetype');}
diff --git a/website/source/assets/stylesheets/application.scss b/website/source/assets/stylesheets/application.scss
new file mode 100755
index 000000000..978a7dea1
--- /dev/null
+++ b/website/source/assets/stylesheets/application.scss
@@ -0,0 +1,30 @@
+@import 'bootstrap-sprockets';
+@import 'bootstrap';
+
+@import url("//fonts.googleapis.com/css?family=Open+Sans:300,400,600,700|Ubuntu+Mono");
+
+// Core variables and mixins
+@import '_variables';
+@import '_mixins';
+
+// Utility classes
+@import '_utilities';
+
+// Core CSS
+@import '_webfonts';
+
+//Global Site
+@import '_global';
+
+// Components
+@import '_header';
+@import '_footer';
+@import '_buttons';
+@import '_sidebar';
+
+// Pages
+@import '_home';
+@import '_community';
+@import '_docs';
+@import '_downloads';
+@import '_api';
diff --git a/website/source/assets/webfonts/2EFB01_0_0.eot b/website/source/assets/webfonts/2EFB01_0_0.eot
new file mode 100644
index 000000000..e840b2722
Binary files /dev/null and b/website/source/assets/webfonts/2EFB01_0_0.eot differ
diff --git a/website/source/assets/webfonts/2EFB01_0_0.ttf b/website/source/assets/webfonts/2EFB01_0_0.ttf
new file mode 100644
index 000000000..7dc8a2098
Binary files /dev/null and b/website/source/assets/webfonts/2EFB01_0_0.ttf differ
diff --git a/website/source/assets/webfonts/2EFB01_0_0.woff b/website/source/assets/webfonts/2EFB01_0_0.woff
new file mode 100644
index 000000000..368c7f26b
Binary files /dev/null and b/website/source/assets/webfonts/2EFB01_0_0.woff differ
diff --git a/website/source/assets/webfonts/2EFB01_0_0.woff2 b/website/source/assets/webfonts/2EFB01_0_0.woff2
new file mode 100644
index 000000000..0ed29aa91
Binary files /dev/null and b/website/source/assets/webfonts/2EFB01_0_0.woff2 differ
diff --git a/website/source/assets/webfonts/2EFC68_0_0.eot b/website/source/assets/webfonts/2EFC68_0_0.eot
new file mode 100644
index 000000000..290553255
Binary files /dev/null and b/website/source/assets/webfonts/2EFC68_0_0.eot differ
diff --git a/website/source/assets/webfonts/2EFC68_0_0.ttf b/website/source/assets/webfonts/2EFC68_0_0.ttf
new file mode 100644
index 000000000..c3744c794
Binary files /dev/null and b/website/source/assets/webfonts/2EFC68_0_0.ttf differ
diff --git a/website/source/assets/webfonts/2EFC68_0_0.woff b/website/source/assets/webfonts/2EFC68_0_0.woff
new file mode 100644
index 000000000..c7bb7b638
Binary files /dev/null and b/website/source/assets/webfonts/2EFC68_0_0.woff differ
diff --git a/website/source/assets/webfonts/2EFC68_0_0.woff2 b/website/source/assets/webfonts/2EFC68_0_0.woff2
new file mode 100644
index 000000000..e9283976c
Binary files /dev/null and b/website/source/assets/webfonts/2EFC68_0_0.woff2 differ
diff --git a/website/source/community.html.erb b/website/source/community.html.erb
new file mode 100644
index 000000000..57d64c39a
--- /dev/null
+++ b/website/source/community.html.erb
@@ -0,0 +1,87 @@
+---
+layout: "inner"
+page_title: "Community"
+description: |-
+  Vault is an open source project with a growing community.
+---
+
+<h1>Community</h1>
+
+<p>
+Vault is an open source project with a growing community. There are
+active, dedicated users willing to help you through various mediums.
+</p>
+<p>
+<strong>IRC:</strong> <code>#vault-tool</code> on Freenode
+</p>
+<p>
+<strong>Mailing list:</strong>
+<a href="https://groups.google.com/group/vault-tool">Vault Google Group</a>
+</p>
+<p>
+<strong>Bug Tracker:</strong>
+<a href="https://github.com/hashicorp/vault/issues">Issue tracker
+	on GitHub</a>. Please only use this for reporting bugs. Do not ask
+for general help here. Use IRC or the mailing list for that.
+
+<h1>People</h1>
+<p>
+The following people are some of the faces behind Vault. They each
+contribute to Vault in some core way. Over time, faces may appear and
+disappear from this list as contributors come and go. In addition to
+the faces below, Vault is a project by
+<a href="https://www.hashicorp.com">HashiCorp</a>, so many HashiCorp
+employees actively contribute to Vault.
+</p>
+<div class="people">
+	<div class="person">
+		<img class="pull-left" src="http://www.gravatar.com/avatar/54079122b67de9677c1f93933ce8b63a.png?s=125">
+		<div class="bio">
+			<h3>Mitchell Hashimoto (<a href="https://github.com/mitchellh">@mitchellh</a>)</h3>
+			<p>
+			Mitchell Hashimoto is the creator of Vault and works on all
+			layers of Vault from the core to backends. In addition to Vault,
+			Mitchell is the creator of
+			<a href="https://www.vagrantup.com">Vagrant</a>,
+			<a href="https://www.packer.io">Packer</a>,
+			<a href="https://www.consul.io">Consul</a>, and
+			<a href="https://www.terraform.io">Terraform</a>.
+			</p>
+		</div>
+	</div>
+
+	<div class="person">
+		<img class="pull-left" src="http://www.gravatar.com/avatar/11ba9630c9136eef9a70d26473d355d5.png?s=125">
+		<div class="bio">
+			<h3>Armon Dadgar (<a href="https://github.com/armon">@armon</a>)</h3>
+			<p>
+			Armon Dadgar is a creator of Vault. He works on all aspects of Vault,
+			focusing on core architecture and security. Armon is also the creator of
+			<a href="https://www.consul.io">Consul</a>,
+			<a href="https://www.serfdom.io">Serf</a>,
+			<a href="https://www.terraform.io">Terraform</a>,
+			<a href="https://github.com/armon/statsite">Statsite</a>, and
+            <a href="https://github.com/armon/bloomd">Bloomd</a>.
+            </p>
+		</div>
+    </div>
+
+	<div class="person">
+		<img class="pull-left" src="http://www.gravatar.com/avatar/2acc31dd6370a54b18f6755cd0710ce6.png?s=125">
+		<div class="bio">
+			<h3>Jack Pearkes (<a href="https://github.com/pearkes">@pearkes</a>)</h3>
+			<p>
+			Jack Pearkes is the creator of the online interactive demo of Vault.
+			He maintains this demo as well as the design and interaction of the
+			Vault website. Jack is an employee of HashiCorp and a primary engineer
+			behind <a href="https://atlas.hashicorp.com">Atlas</a>.
+			He is also a core committer to
+			<a href="https://www.packer.io">Packer</a>,
+			<a href="https://www.consul.io">Consul</a>, and
+			<a href="https://www.terraform.io">Terraform</a>.
+			</p>
+		</div>
+    </div>
+
+    <div class="clearfix"></div>
+</div>
diff --git a/website/source/docs/audit/file.html.md b/website/source/docs/audit/file.html.md
new file mode 100644
index 000000000..b46174b2d
--- /dev/null
+++ b/website/source/docs/audit/file.html.md
@@ -0,0 +1,36 @@
+---
+layout: "docs"
+page_title: "Audit Backend: File"
+sidebar_current: "docs-audit-file"
+description: |-
+  The "file" audit backend writes audit logs to a file.
+---
+
+# Audit Backend: File
+
+Name: `file`
+
+The "file" audit backend writes audit logs to a file.
+
+This is a very simple audit backend: it appends logs to a file. It does
+not currently assist with any log rotation.
+
+## Options
+
+When enabling this backend, the following options are accepted:
+
+  * `path` (required) - The path to where the file will be written. If
+      this path exists, the audit backend will append to it.
+  * `log_raw` (optional) Should security sensitive information be logged raw. Defaults to "false".
+
+## Format
+
+Each line in the audit log is a JSON object. The "type" field specifies
+what type of object it is. Currently, only two types exist: "request" and
+"response".
+
+The line contains all of the information for any given request and response.
+
+If `log_raw` if false, as is default, all sensitive information is first hashed
+before logging. If explicitly enabled, all values are logged raw without hashing.
+
diff --git a/website/source/docs/audit/index.html.md b/website/source/docs/audit/index.html.md
new file mode 100644
index 000000000..51f89303d
--- /dev/null
+++ b/website/source/docs/audit/index.html.md
@@ -0,0 +1,67 @@
+---
+layout: "docs"
+page_title: "Audit Backends"
+sidebar_current: "docs-audit"
+description: |-
+  Audit backends are mountable backends that log requests and responses in Vault.
+---
+
+# Audit Backends
+
+Audit backends are the components in Vault that keep a detailed log
+of all requests and response to Vault. Because _every_ operation with
+Vault is an API request/response, the audit log contains _every_ interaction
+with Vault, including errors.
+
+Vault ships with multiple audit backends, depending on the location you want
+the logs sent to. Multiple audit backends can be enabled and Vault will send
+the audit logs to both. This allows you to not only have a redundant copy,
+but also a second copy in case the first is tampered with.
+
+## Sensitive Information
+
+The audit logs contain the full request and response objects for every
+interaction with Vault. The data in the request and the data in the
+response (including secrets and authentication tokens) will be hashed
+without a salt using SHA1.
+
+The purpose of the hash is so that secrets aren't in plaintext within
+your audit logs. However, you're still able to check the value of
+secrets by SHA-ing it yourself.
+
+## Enabling/Disabling Audit Backends
+
+When a Vault server is first initialized, no auditing is enabled. Audit
+backends must be enabled by a root user using `vault audit-enable`.
+
+When enabling an audit backend, options can be passed to it to configure it.
+For example, the command below enables the file audit backend:
+
+```
+$ vault audit-enable file path=/var/log/vault_audit.log
+...
+```
+
+In the command above, we passed the "path" parameter to specify the path
+where the audit log will be written to. Each audit backend has its own
+set of parameters. See the documentation to the left for more details.
+
+When an audit backend is disabled, it will stop receiving logs immediately.
+The existing logs that it did store are untouched.
+
+## Blocked Audit Backends
+
+If there are any audit backends enabled, Vault requires that at least
+one be able to persist the log before completing a Vault request.
+
+If you have only one audit backend enabled, and it is blocking (network
+block, etc.), then Vault will be _unresponsive_. Vault _will not_ complete
+any requests until the audit backend can write.
+
+If you have more than one audit backend, then Vault will complete the request
+as long as one audit backend persists the log.
+
+Vault will not respond to requests if audit backends are blocked because
+audit logs are critically important and ignoring blocked requests opens
+an avenue for attack. Be absolutely certain that your audit backends cannot
+block.
diff --git a/website/source/docs/audit/syslog.html.md b/website/source/docs/audit/syslog.html.md
new file mode 100644
index 000000000..2b0a94025
--- /dev/null
+++ b/website/source/docs/audit/syslog.html.md
@@ -0,0 +1,37 @@
+---
+layout: "docs"
+page_title: "Audit Backend: Syslog"
+sidebar_current: "docs-audit-syslog"
+description: |-
+  The "syslog" audit backend writes audit logs to syslog.
+---
+
+# Audit Backend: Syslog
+
+Name: `syslog`
+
+The "syslog" audit backend writes audit logs to syslog.
+
+It currently does not support a configurable syslog destination, and
+always sends to the local agent. This backend is only supported on Unix systems,
+and should not be enabled if any standby Vault instances do not support it.
+
+## Options
+
+When enabling this backend, the following options are accepted:
+
+ * `facility` (optional) - The syslog facility to use. Defaults to "AUTH".
+ * `tag` (optional) - The syslog tag to use. Defaults to "vault".
+ * `log_raw` (optional) Should security sensitive information be logged raw. Defaults to "false".
+
+## Format
+
+Each line in the audit log is a JSON object. The "type" field specifies
+what type of object it is. Currently, only two types exist: "request" and
+"response".
+
+The line contains all of the information for any given request and response.
+
+If `log_raw` if false, as is default, all sensitive information is first hashed
+before logging. If explicitly enabled, all values are logged raw without hashing.
+
diff --git a/website/source/docs/auth/app-id.html.md b/website/source/docs/auth/app-id.html.md
new file mode 100644
index 000000000..579930fc8
--- /dev/null
+++ b/website/source/docs/auth/app-id.html.md
@@ -0,0 +1,119 @@
+---
+layout: "docs"
+page_title: "Auth Backend: App ID"
+sidebar_current: "docs-auth-appid"
+description: |-
+  The App ID auth backend is a mechanism for machines to authenticate with Vault.
+---
+
+# Auth Backend: App ID
+
+Name: `app-id`
+
+The App ID auth backend is a mechanism for machines to authenticate with
+Vault. It works by requiring two hard-to-guess unique pieces of information:
+a unique app ID, and a unique user ID.
+
+The goal of this credential provider is to allow elastic users
+(dynamic machines, containers, etc.) to authenticate with Vault without
+having to store passwords outside of Vault. It is a single method of
+solving the chicken-and-egg problem of setting up Vault access on a machine.
+With this provider, nobody except the machine itself has access to both
+pieces of information necessary to authenticate. For example:
+configuration management will have the app IDs, but the machine itself
+will detect its user ID based on some unique machine property such as a
+MAC address (or a hash of it with some salt).
+
+An example, real world process for using this provider:
+
+  1. Create unique app IDs (UUIDs work well) and map them to policies.
+     (Path: map/app-id/<app-id>)
+
+  2. Store the app IDs within configuration management systems.
+
+  3. An out-of-band process run by security operators map unique user IDs
+     to these app IDs. Example: when an instance is launched, a cloud-init
+     system tells security operators a unique ID for this machine. This
+     process can be scripted, but the key is that it is out-of-band and
+     out of reach of configuration management.
+   (Path: map/user-id/<user-id>)
+
+  4. A new server is provisioned. Configuration management configures the
+     app ID, the server itself detects its user ID. With both of these
+     pieces of information, Vault can be accessed according to the policy
+     set by the app ID.
+
+More details on this process follow:
+
+The app ID is a unique ID that maps to a set of policies. This ID is
+generated by an operator and configured into the backend. The ID itself
+is usually a UUID, but any hard-to-guess unique value can be used.
+
+After creating app IDs, an operator authorizes a fixed set of user IDs
+with each app ID. When a valid {app ID, user ID} tuple is given to the
+"login" path, then the user is authenticated with the configured app
+ID policies.
+
+The user ID can be any value (just like the app ID), however it is
+generally a value unique to a machine, such as a MAC address or instance ID,
+or a value hashed from these unique values.
+
+
+## Authentication
+
+#### Via the CLI
+
+App ID authentication is not allowed via the CLI.
+
+#### Via the API
+
+The endpoint for the App ID login is `/login`. The client is expected
+to provide the `app_id` and `user_id` parameters as part of the request.
+
+## Configuration
+
+First you must enable the App ID auth backend:
+
+```
+$ vault auth-enable app-id
+Successfully enabled 'app-id' at 'app-id'!
+```
+
+Now when you run `vault auth -methods`, the App ID backend is available:
+
+```
+Path       Type      Description
+app-id/    app-id
+token/     token     token based credentials
+```
+
+To use the App ID auth backend, an operator must configure it with
+the set of App IDs, user IDs, and the mapping between them. An
+example is shown below, use `vault path-help` for more details.
+
+```
+$ vault write auth/app-id/map/app-id/foo value=root display_name=foo
+...
+
+$ vault write auth/app-id/map/user-id/bar value=foo cidr_block=10.0.0.0/16
+...
+```
+
+The above creates an App ID "foo" that associates with the policy "root".
+The `display_name` sets the display name for audit logs and secrets.
+Next, we configure the user ID "bar" and say that the user ID bar
+can be paired with "foo" but only if the client is in the "10.0.0.0/16" CIDR block.
+The `cidr_block` configuration is optional.
+
+This means that if a client authenticates and provide both "foo" and "bar",
+then the app ID will authenticate that client with the policy "root".
+
+In practice, both the user and app ID are likely hard-to-guess UUID-like values.
+
+Note that it is possible to authorize multiple app IDs with each
+user ID by writing them as comma-separated values to the user ID mapping:
+
+```
+$ vault write auth/app-id/map/user-id/bar value=foo,baz cidr_block=10.0.0.0/16
+...
+```
diff --git a/website/source/docs/auth/cert.html.md b/website/source/docs/auth/cert.html.md
new file mode 100644
index 000000000..b2cb75166
--- /dev/null
+++ b/website/source/docs/auth/cert.html.md
@@ -0,0 +1,68 @@
+---
+layout: "docs"
+page_title: "Auth Backend: TLS Certificates"
+sidebar_current: "docs-auth-cert"
+description: |-
+  The "cert" auth backend allows users to authenticate with Vault using TLS client certificates.
+---
+
+# Auth Backend: TLS Certificates
+
+Name: `cert`
+
+The "cert" auth backend allows authentication using SSL/TLS client certificates
+which are either signed by a CA or self-signed.
+
+The trusted certificates and CAs are configured directly to the auth
+backend using the `certs/` path. This backend cannot read trusted certificates
+from an external source.
+
+## Authentication
+
+### Via the CLI
+```
+vault auth -method=cert \
+  -ca-cert=ca.pem -client-cert=cert.pem -client-key=key.pem
+```
+
+### Via the API
+The endpoint for the login is `/login`. The client simply connects with their TLS
+certificate and when the login endpoint is hit, the auth backend will determine
+if there is a matching trusted certificate to authenticate the client.
+
+```
+curl --cacert ca.pem --cert cert.pem --key key.pem \
+  $VAULT_ADDR/v1/auth/cert/login -XPOST
+```
+
+## Configuration
+
+First, you must enable the certificate auth backend:
+
+```
+$ vault auth-enable cert
+Successfully enabled 'cert' at 'cert'!
+```
+
+Now when you run `vault auth -methods`, the certificate backend is available:
+
+```
+Path       Type      Description
+cert/      cert
+token/     token     token based credentials
+```
+
+To use the "cert" auth backend, an operator must configure it with
+trusted certificates that are allowed to authenticate. An example is shown below.
+Use `vault path-help` for more details.
+
+```
+$ vault write auth/cert/certs/web display_name=web policies=web,prod certificate=@web-cert.pem lease=3600
+...
+```
+
+The above creates a new trusted certificate "web" with same display name
+and the "web" and "prod" policies. The certificate (public key) used to verify
+clients is given by the "web-cert.pem" file. Lastly, an optional lease value
+can be provided in seconds to limit the lease period.
+
diff --git a/website/source/docs/auth/github.html.md b/website/source/docs/auth/github.html.md
new file mode 100644
index 000000000..5d290a9ef
--- /dev/null
+++ b/website/source/docs/auth/github.html.md
@@ -0,0 +1,86 @@
+---
+layout: "docs"
+page_title: "Auth Backend: GitHub"
+sidebar_current: "docs-auth-github"
+description: |-
+  The GitHub auth backend allows authentication with Vault using GitHub.
+---
+
+# Auth Backend: GitHub
+
+Name: `github`
+
+The GitHub auth backend can be used to authenticate with Vault using
+a GitHub personal access token.
+This method of authentication is most useful for humans: operators or
+developers using Vault directly via the CLI.
+
+## Authentication
+
+#### Via the CLI
+
+```
+$ vault auth -method=github token=<api token>
+...
+```
+
+#### Via the API
+
+The endpoint for the GitHub login is `/login`.
+
+## Configuration
+
+First, you must enable the GitHub auth backend:
+
+```
+$ vault auth-enable github
+Successfully enabled 'github' at 'github'!
+```
+
+Now when you run `vault auth -methods`, the GitHub backend is available:
+
+```
+Path       Type      Description
+github/    github
+token/     token     token based credentials
+```
+
+Prior to using the GitHub auth backend, it must be configured. To
+configure it, use the `/config` endpoint with the following arguments:
+
+  * `organization` (string, required) - The organization name a user must
+       be a part of to authenticate.
+
+###Generate a GitHub Personal Access Token
+Access your Personal Access Tokens in GitHub at [https://github.com/settings/tokens](https://github.com/settings/tokens).
+Generate a new Token that has the scope `read:org`. Save the generated token. This is what you will provide to vault.
+
+For example:
+
+```
+$ vault write auth/github/config organization=hashicorp
+Success! Data written to: auth/github/config
+```
+
+After configuring that, you must map the teams of that organization to
+policies within Vault. Use the `map/teams/<team>` endpoints to do that.
+Example:
+
+```
+$ vault write auth/github/map/teams/owners value=root
+Success! Data written to: auth/github/map/teams/owners
+```
+
+The above would make anyone in the "owners" team a root user in Vault
+(not recommended).
+
+You can then auth with a user that is a member of the "owners" team using a Personal Access Token with the `read:org` scope.
+
+```
+$ vault auth -method=github token=000000905b381e723b3d6a7d52f148a5d43c4b45
+Successfully authenticated! The policies that are associated
+with this token are listed below:
+
+root
+```
+
diff --git a/website/source/docs/auth/index.html.md b/website/source/docs/auth/index.html.md
new file mode 100644
index 000000000..210505fa2
--- /dev/null
+++ b/website/source/docs/auth/index.html.md
@@ -0,0 +1,40 @@
+---
+layout: "docs"
+page_title: "Auth Backends"
+sidebar_current: "docs-auth"
+description: |-
+  Auth backends are mountable backends that perform authentication for Vault.
+---
+
+# Auth Backends
+
+Auth backends are the components in Vault that perform authentication
+and are responsible for assigning identity and a set of policies to a
+user.
+
+Having multiple auth backends enables you to use an auth backend
+that makes the sense for your use case of Vault and your organization.
+
+For example, on developer machines, the [GitHub auth backend](/docs/auth/github.html)
+is easiest to use. But for servers the [App ID](/docs/auth/app-id.html)
+backend is the recommended choice.
+
+To learn more about authentication, see the
+[authentication concepts page](/docs/concepts/auth.html).
+
+## Enabling/Disabling Auth Backends
+
+Auth backends can be enabled/disabled using the CLI or the API.
+
+When enabled, auth backends are similar to [secret backends](/docs/secrets/index.html):
+they are mounted within the Vault mount table and can be accessed
+and configured using the standard read/write API. The only difference
+is that all auth backends are mounted underneath the `auth/` prefix.
+
+By default, auth backends are mounted to `auth/<type>`. For example,
+if you enable "github", then you can interact with it at `auth/github`.
+However, this path is customizable, allowing users with advanced use
+cases to mount a single auth backend multiple times.
+
+When an auth backend is disabled, all users authenticated via that
+backend are automatically logged out.
diff --git a/website/source/docs/auth/ldap.html.md b/website/source/docs/auth/ldap.html.md
new file mode 100644
index 000000000..cf4c2fb5b
--- /dev/null
+++ b/website/source/docs/auth/ldap.html.md
@@ -0,0 +1,131 @@
+---
+layout: "docs"
+page_title: "Auth Backend: LDAP"
+sidebar_current: "docs-auth-ldap"
+description: |-
+  The "ldap" auth backend allows users to authenticate with Vault using LDAP credentials.
+---
+
+# Auth Backend: LDAP
+
+Name: `ldap`
+
+The "ldap" auth backend allows authentication using an existing LDAP
+server and user/password credentials. This allows Vault to be integrated
+into environments using LDAP without duplicating the user/pass configuration
+in multiple places.
+
+The mapping of groups in LDAP to Vault policies is managed by using the
+`users/` and `groups/` paths.
+
+## Authentication
+
+#### Via the CLI
+
+```
+$ vault auth -method=ldap username=mitchellh
+Password (will be hidden):
+Successfully authenticated! The policies that are associated
+with this token are listed below:
+
+root
+```
+
+#### Via the API
+
+The endpoint for the login is `auth/ldap/login/<username>`.
+
+The password should be sent in the POST body encoded as JSON.
+
+```shell
+$ curl $VAULT_ADDR/v1/auth/ldap/login/mitchellh \
+    -d '{ "password": "foo" }'
+```
+
+The response will be in JSON. For example:
+
+```javascript
+{
+  "lease_id":"",
+  "renewable":false,
+  "lease_duration":0,
+  "data":null,
+  "auth":{
+    "client_token":"c4f280f6-fdb2-18eb-89d3-589e2e834cdb",
+    "policies":[
+      "root"
+    ],
+    "metadata":{
+      "username":"mitchellh"
+    },
+    "lease_duration":0,
+    "renewable":false
+  }
+}
+```
+
+## Configuration
+
+First, you must enable the ldap auth backend:
+
+```
+$ vault auth-enable ldap
+Successfully enabled 'ldap' at 'ldap'!
+```
+
+Now when you run `vault auth -methods`, the ldap backend is available:
+
+```
+Path       Type      Description
+ldap/      ldap
+token/     token     token based credentials
+```
+
+To use the "ldap" auth backend, an operator must configure it with
+the address of the LDAP server that is to be used. An example is shown below.
+Use `vault path-help` for more details.
+
+```
+$ vault write auth/ldap/config url="ldap://ldap.forumsys.com" \
+		userattr=uid \
+        userdn="dc=example,dc=com" \
+        groupdn="dc=example,dc=com" \
+        upndomain="forumsys.com" \
+        certificate=@ldap_ca_cert.pem \
+        insecure_tls=false \
+        starttls=true
+...
+```
+
+The above configures the target LDAP server, along with the parameters
+specifying how users and groups should be queried from the LDAP server.
+
+Next we want to create a mapping from an LDAP group to a Vault policy:
+
+```
+$ vault write auth/ldap/groups/scientists policies=foo,bar
+```
+
+This maps the LDAP group "scientists" to the "foo" and "bar" Vault policies.
+
+We can also add specific LDAP users to additional (potentially non-LDAP) groups:
+
+```
+$ vault write auth/ldap/groups/engineers policies=foobar
+$ vault write auth/ldap/users/tesla groups=engineers
+```
+
+This adds the LDAP user "tesla" to the "engineers" group, which maps to
+the "foobar" Vault policy.
+
+Finally, we can test this by authenticating:
+
+```
+$ vault auth -method=ldap username=tesla
+Password (will be hidden):
+Successfully authenticated! The policies that are associated
+with this token are listed below:
+
+bar, foo, foobar
+```
+
diff --git a/website/source/docs/auth/mfa.html.md b/website/source/docs/auth/mfa.html.md
new file mode 100644
index 000000000..a58c78cd4
--- /dev/null
+++ b/website/source/docs/auth/mfa.html.md
@@ -0,0 +1,92 @@
+---
+layout: "docs"
+page_title: "Multi-Factor Authentication"
+sidebar_current: "docs-auth-mfa"
+description: |-
+  Multi-factor authentication is supported for several authentication backends.
+---
+
+# Multi-Factor Authentication
+
+Several authentication backends support multi-factor authentication (MFA). Once enabled for
+a backend, users are required to provide additional verification, like a one-time passcode,
+before being authenticated.
+
+Currently, the "ldap" and "userpass" backends support MFA.
+
+## Authentication
+
+When authenticating, users still provide the same information as before, in addition to
+MFA verification. Usually this is a passcode, but in other cases, like a Duo Push
+notification, no additional information is needed.
+
+### Via the CLI
+
+```shell
+$ vault auth -method=userpass \
+    username=user \
+    password=test \
+    passcode=111111
+```
+```shell
+$ vault auth -method=userpass \
+    username=user \
+    password=test \
+    method=push
+```
+
+### Via the API
+
+The endpoint for the login is the same as for the original backend. Additional
+MFA information should be sent in the POST body encoded as JSON.
+
+```shell
+$ curl $VAULT_ADDR/v1/auth/userpass/login/user \
+    -d '{ "password": "test", "passcode": "111111" }'
+```
+
+The response is the same as for the original backend.
+
+## Configuration
+
+To enable MFA for a supported backend, the MFA type must be set in `mfa_config`. For example:
+
+```shell
+$ vault write auth/userpass/mfa_config type=duo
+```
+
+This enables the Duo MFA type, which is currently the only MFA type supported. The username
+used for MFA is the same as the login username, unless the backend or MFA type provide
+options to behave differently (see Duo configuration below).
+
+### Duo
+
+The Duo MFA type is configured through two paths: `duo/config` and `duo/access`. 
+
+`duo/access` contains connection information for the Duo Auth API. To configure:
+
+```shell
+$ vault write auth/[mount]/duo/access \
+    host=[host] \
+    ikey=[integration key] \
+    skey=[secret key]
+```
+
+`duo/config` is an optional path that contains general configuration information
+for Duo authentication. To configure:
+
+```shell
+$ vault write auth/[mount]/duo/config \
+    user_agent="" \
+    username_format="%s"
+```
+
+`user_agent` is the user agent to use when connecting to Duo.
+
+`username_format` controls how the username used to login is
+transformed before authenticating with Duo. This field is a format string
+that is passed the original username as its first argument and outputs
+the new username. For example "%s@example.com" would append "@example.com"
+to the provided username before connecting to Duo.
+
+More information can be found through the CLI `path-help` command.
diff --git a/website/source/docs/auth/token.html.md b/website/source/docs/auth/token.html.md
new file mode 100644
index 000000000..83763cd23
--- /dev/null
+++ b/website/source/docs/auth/token.html.md
@@ -0,0 +1,326 @@
+---
+layout: "docs"
+page_title: "Auth Backend: Token"
+sidebar_current: "docs-auth-token"
+description: |-
+  The token store auth backend is used to authenticate using tokens.
+---
+
+# Auth Backend: Token
+
+The token backend is the only auth backend that is built-in and
+automatically available at `/auth/token` as well as with first-class
+built-in CLI methods such as `vault token-create`. It allows users to
+authenticate using a token, as well to create new tokens, revoke
+secrets by token, and more.
+
+When any other auth backend returns an identity, Vault core invokes the
+token backend to create a new unique token for that identity.
+
+The token store can also be used to bypass any other auth backend:
+you can create tokens directly, as well as perform a variety of other
+operations on tokens such as renewal and revocation.
+
+Please see the [token concepts](/docs/concepts/tokens.html) page dedicated
+to tokens.
+
+## Authentication
+
+#### Via the CLI
+
+```
+$ vault auth <token>
+...
+```
+
+#### Via the API
+
+The token is set directly as a cookie for the HTTP API. The name
+of the cookie should be "token" and the value should be the token.
+
+## API
+
+### /auth/token/create
+#### POST
+
+<dl class="api">
+  <dt>Description</dt>
+  <dd>
+    Creates a new token. Certain options are only available to
+    when called by a root token.
+  </dd>
+
+  <dt>Method</dt>
+  <dd>POST</dd>
+
+  <dt>URL</dt>
+  <dd>`/auth/token/create`</dd>
+
+  <dt>Parameters</dt>
+  <dd>
+    <ul>
+      <li>
+        <span class="param">id</span>
+        <span class="param-flags">optional</span>
+        The ID of the client token. Can only be specified by a root token.
+        Otherwise, the token ID is a randomly generated UUID.
+      </li>
+      <li>
+        <span class="param">policies</span>
+        <span class="param-flags">optional</span>
+        A list of policies for the token. This must be a subset of the
+        policies belonging to the token making the request, unless root.
+        If not specified, defaults to all the policies of the calling token.
+      </li>
+      <li>
+        <span class="param">meta</span>
+        <span class="param-flags">optional</span>
+        A map of string to string valued metadata. This is passed through
+        to the audit backends.
+      </li>
+      <li>
+        <span class="param">no_parent</span>
+        <span class="param-flags">optional</span>
+        If true and set by a root caller, the token will not have the
+        parent token of the caller. This creates a token with no parent.
+      </li>
+      <li>
+        <span class="param">lease</span>
+        <span class="param-flags">optional</span>
+        The lease period of the token, provided as "1h", where hour is
+        the largest suffix. If not provided, the token is valid for the
+        [default lease duration](/docs/config/index.html), or
+        indefinitely if the root policy is used.
+      </li>
+      <li>
+        <span class="param">display_name</span>
+        <span class="param-flags">optional</span>
+        The display name of the token. Defaults to "token".
+      </li>
+      <li>
+        <span class="param">num_uses</span>
+        <span class="param-flags">optional</span>
+        The maximum uses for the given token. This can be used to create
+        a one-time-token or limited use token. Defaults to 0, which has
+        no limit to number of uses.
+      </li>
+    </ul>
+  </dd>
+
+  <dt>Returns</dt>
+  <dd>
+
+      ```javascript
+    {
+      "auth": {
+          "client_token": "ABCD",
+          "policies": ["web", "stage"],
+          "metadata": {"user": "armon"},
+          "lease_duration": 3600,
+          "renewable": true,
+      }
+    }
+    ```
+
+  </dd>
+</dl>
+
+### /auth/token/lookup-self
+#### GET
+
+<dl class="api">
+  <dt>Description</dt>
+  <dd>
+    Returns information about the current client token.
+  </dd>
+
+  <dt>Method</dt>
+  <dd>GET</dd>
+
+  <dt>Parameters</dt>
+  <dd>
+    None
+  </dd>
+
+  <dt>Returns</dt>
+  <dd>
+
+    ```javascript
+    {
+      "data": {
+        "id": "ClientToken",
+        "policies": ["web", "stage"],
+        "path": "auth/github/login",
+        "meta": {"user": "armon", "organization": "hashicorp"},
+        "display_name": "github-armon",
+        "num_uses": 0,
+      }
+    }
+    ```
+  </dd>
+</dl>
+
+### /auth/token/lookup/
+#### GET
+
+<dl class="api">
+  <dt>Description</dt>
+  <dd>
+    Returns information about the current client token.
+  </dd>
+
+  <dt>Method</dt>
+  <dd>GET</dd>
+
+  <dt>URL</dt>
+  <dd>`/auth/token/lookup/<token>`</dd>
+
+  <dt>Parameters</dt>
+  <dd>
+    None
+  </dd>
+
+  <dt>Returns</dt>
+  <dd>
+
+    ```javascript
+    {
+      "data": {
+        "id": "ClientToken",
+        "policies": ["web", "stage"],
+        "path": "auth/github/login",
+        "meta": {"user": "armon", "organization": "hashicorp"},
+        "display_name": "github-armon",
+        "num_uses": 0,
+      }
+    }
+    ```
+  </dd>
+</dl>
+
+
+### /auth/token/revoke/
+#### POST
+
+<dl class="api">
+  <dt>Description</dt>
+  <dd>
+    Revokes a token and all child tokens. When the token is revoked,
+    all secrets generated with it are also revoked.
+  </dd>
+
+  <dt>Method</dt>
+  <dd>POST</dd>
+
+  <dt>URL</dt>
+  <dd>`/auth/token/revoke/<token>`</dd>
+
+  <dt>Parameters</dt>
+  <dd>
+    None
+  </dd>
+
+  <dt>Returns</dt>
+  <dd>`204` response code.
+  </dd>
+</dl>
+
+### /auth/token/revoke-orphan/
+#### POST
+
+<dl class="api">
+  <dt>Description</dt>
+  <dd>
+    Revokes a token but not its child tokens. When the token is revoked,
+    all secrets generated with it are also revoked. All child tokens
+    are orphaned, but can be revoked sub-sequently using `/auth/token/revoke/`.
+  </dd>
+
+  <dt>Method</dt>
+  <dd>POST</dd>
+
+  <dt>URL</dt>
+  <dd>`/auth/token/revoke-orphan/<token>`</dd>
+
+  <dt>Parameters</dt>
+  <dd>
+    None
+  </dd>
+
+  <dt>Returns</dt>
+  <dd>`204` response code.
+  </dd>
+</dl>
+
+### /auth/token/revoke-prefix/
+#### POST
+
+<dl class="api">
+  <dt>Description</dt>
+  <dd>
+    Revokes all tokens generated at a given prefix, along with child tokens,
+    and all secrets generated using those tokens. Uses include revoking all
+    tokens generated by a credential backend during a suspected compromise.
+  </dd>
+
+  <dt>Method</dt>
+  <dd>POST</dd>
+
+  <dt>URL</dt>
+  <dd>`/auth/token/revoke-prefix/<prefix>`</dd>
+
+  <dt>Parameters</dt>
+  <dd>
+    None
+  </dd>
+
+  <dt>Returns</dt>
+  <dd>`204` response code.
+  </dd>
+</dl>
+
+### /auth/token/renew/
+#### POST
+
+<dl class="api">
+  <dt>Description</dt>
+  <dd>
+    Renews a lease associated with a token. This is used to prevent
+    the expiration of a token, and the automatic revocation of it.
+  </dd>
+
+  <dt>Method</dt>
+  <dd>POST</dd>
+
+  <dt>URL</dt>
+  <dd>`/auth/token/renew/<token>`</dd>
+
+  <dt>Parameters</dt>
+  <dd>
+    <ul>
+      <li>
+        <span class="param">increment</span>
+        <span class="param-flags">optional</span>
+            An optional requested lease increment can be provided. This
+            increment may be ignored.
+      </li>
+    </ul>
+  </dd>
+
+  <dt>Returns</dt>
+  <dd>
+
+    ```javascript
+    {
+      "auth": {
+          "client_token": "ABCD",
+          "policies": ["web", "stage"],
+          "metadata": {"user": "armon"},
+          "lease_duration": 3600,
+          "renewable": true,
+      }
+    }
+    ```
+  </dd>
+</dl>
+</div>
diff --git a/website/source/docs/auth/userpass.html.md b/website/source/docs/auth/userpass.html.md
new file mode 100644
index 000000000..32e795938
--- /dev/null
+++ b/website/source/docs/auth/userpass.html.md
@@ -0,0 +1,92 @@
+---
+layout: "docs"
+page_title: "Auth Backend: Username & Password"
+sidebar_current: "docs-auth-userpass"
+description: |-
+  The "userpass" auth backend allows users to authenticate with Vault using a username and password.
+---
+
+# Auth Backend: Username & Password
+
+Name: `userpass`
+
+The "userpass" auth backend allows users to authenticate with Vault using
+a username and password combination.
+
+The username/password combinations are configured directly to the auth
+backend using the `users/` path. This backend cannot read usernames and
+passwords from an external source.
+
+## Authentication
+
+#### Via the CLI
+
+```
+$ vault auth -method=userpass \
+  username=foo \
+  password=bar
+```
+
+#### Via the API
+
+The endpoint for the login is `auth/userpass/login/<username>`.
+
+The password should be sent in the POST body encoded as JSON.
+
+```shell
+$ curl $VAULT_ADDR/v1/auth/userpass/login/mitchellh \
+    -d '{ "password": "foo" }'
+```
+
+The response will be in JSON. For example:
+
+```javascript
+{
+  "lease_id":"",
+  "renewable":false,
+  "lease_duration":0,
+  "data":null,
+  "auth":{
+    "client_token":"c4f280f6-fdb2-18eb-89d3-589e2e834cdb",
+    "policies":[
+      "root"
+    ],
+    "metadata":{
+      "username":"mitchellh"
+    },
+    "lease_duration":0,
+    "renewable":false
+  }
+}
+```
+
+## Configuration
+
+First, you must enable the username/password auth backend:
+
+```
+$ vault auth-enable userpass
+Successfully enabled 'userpass' at 'userpass'!
+```
+
+Now when you run `vault auth -methods`, the username/password backend is
+available:
+
+```
+Path       Type      Description
+token/     token     token based credentials
+userpass/  userpass
+```
+
+To use the "userpass" auth backend, an operator must configure it with
+users that are allowed to authenticate. An example is shown below.
+Use `vault path-help` for more details.
+
+```
+$ vault write auth/userpass/users/mitchellh password=foo policies=root
+...
+```
+
+The above creates a new user "mitchellh" with the password "foo" that
+will be associated with the "root" policy. This is the only configuration
+necessary.
diff --git a/website/source/docs/commands/help.html.md b/website/source/docs/commands/help.html.md
new file mode 100644
index 000000000..48f596b46
--- /dev/null
+++ b/website/source/docs/commands/help.html.md
@@ -0,0 +1,106 @@
+---
+layout: "docs"
+page_title: "Path Help"
+sidebar_current: "docs-commands-path-help"
+description: |-
+  The Vault CLI has a built-in help system that can be used to get help for not only the CLI itself, but also any paths that the CLI can be used with within Vault.
+---
+
+# Help
+
+In addition to standard CLI help using the `-h` or `-help` flag for
+commands, Vault has a built-in `path-help` command that can be used to get
+help for specific paths within Vault. These paths are used with the
+API or `read, write, delete` commands in order to interact with Vault.
+
+The help system is the easiest way to learn how to use the various systems
+in Vault, and also allows you to discover new paths.
+
+-> **Important!** The help system is incredibly important in day-to-day
+use of Vault. As a beginner or experienced user of Vault, you'll be using
+the help command a lot to remember how to use different components of
+Vault. Note that the Vault Server must be running and the client configured
+properly to execute this command to look up paths.
+
+## Discovering Paths
+
+Before using `path-help`, it is important to understand "paths" within Vault.
+Paths are the parameters used for `vault read`, `vault write`, etc. An
+example path is `secret/foo`, or `aws/config/root`. The paths available
+depend on the mounted secret backends. Because of this, the interactive
+help is an indispensable tool to finding what paths are supported.
+
+To discover what paths are supported, use `vault path-help <mount point>`.
+For example, if you mounted the AWS secret backend, you can use
+`vault path-help aws` to find the paths supported by that backend. The paths
+will be shown with regular expressions, which can make them hard to
+parse, but they're also extremely exact.
+
+You can try it right away with any Vault with `vault path-help secret`, since
+`secret` is always mounted initially. The output from this command is shown
+below and contains both a description of what that backend is for, along with
+the paths it supports.
+
+```
+$ vault path-help secret
+## DESCRIPTION
+
+The generic backend reads and writes arbitrary secrets to the backend.
+The secrets are encrypted/decrypted by Vault: they are never stored
+unencrypted in the backend and the backend never has an opportunity to
+see the unencrypted value.
+
+Leases can be set on a per-secret basis. These leases will be sent down
+when that secret is read, and it is assumed that some outside process will
+revoke and/or replace the secret at that path.
+
+## PATHS
+
+The following paths are supported by this backend. To view help for
+any of the paths below, use the help command with any route matching
+the path pattern. Note that depending on the policy of your auth token,
+you may or may not be able to access certain paths.
+
+    ^.*$
+        Pass-through secret storage to the storage backend, allowing you to
+        read/write arbitrary data into secret storage.
+```
+
+## Single Path
+
+Once you've found a path you like, you can learn more about it by
+using `vault path-help <path>` where "path" is a path that matches one of the
+regular expressions from the backend help.
+
+Or, if you saw an example online with `vault write` or some similar
+command, you can plug that directly into `vault path-help` to learn about it
+(assuming you have the proper backends mounted!).
+
+For example, below we get the help for a single secret in the `secret/`
+mount point. The help shows the operations that that path supports, the
+parameters it takes (for write), and a description of that specific path.
+
+```
+$ vault path-help secret/password
+Request:        password
+Matching Route: ^.*$
+
+Pass-through secret storage to the storage backend, allowing you to
+read/write arbitrary data into secret storage.
+
+## PARAMETERS
+
+    lease (string)
+        Lease time for this key when read. Ex: 1h
+
+## DESCRIPTION
+
+The pass-through backend reads and writes arbitrary data into secret storage,
+encrypting it along the way.
+
+A lease can be specified when writing with the "lease" field. If given, then
+when the secret is read, Vault will report a lease with that duration. It
+is expected that the consumer of this backend properly writes renewed keys
+before the lease is up. In addition, revocation must be handled by the
+user of this backend.
+```
diff --git a/website/source/docs/commands/index.html.md b/website/source/docs/commands/index.html.md
new file mode 100644
index 000000000..08e106965
--- /dev/null
+++ b/website/source/docs/commands/index.html.md
@@ -0,0 +1,26 @@
+---
+layout: "docs"
+page_title: "Commands (CLI)"
+sidebar_current: "docs-commands"
+description: |-
+  Vault can be controlled via a command-line interface. This page documents all the commands Vault accepts.
+---
+
+# Vault Commands (CLI)
+
+Vault is controlled via a very easy to use command-line interface (CLI).
+Vault is only a single command-line application: `vault`. This application
+then takes a subcommand such as "read" or "write". The complete list of
+subcommands is in the navigation to the left.
+
+The Vault CLI is a well-behaved command line application. In erroneous cases,
+a non-zero exit status will be returned. It also responds to `-h` and `--help`
+as you'd most likely expect.
+
+To view a list of the available commands at any time, just run Vault
+with no arguments. To get help for any specific subcommand, run the subcommand
+with the `-h` argument.
+
+The help output is very comprehensive, so we defer you to that for documentation.
+We've included some guides to the left of common interactions with the
+CLI.
diff --git a/website/source/docs/commands/read-write.html.md b/website/source/docs/commands/read-write.html.md
new file mode 100644
index 000000000..4796d9135
--- /dev/null
+++ b/website/source/docs/commands/read-write.html.md
@@ -0,0 +1,118 @@
+---
+layout: "docs"
+page_title: "Reading and Writing Data"
+sidebar_current: "docs-commands-readwrite"
+description: |-
+  The Vault CLI can be used to read, write, and delete secrets. This page documents how to do this.
+---
+
+# Reading and Writing Data with the CLI
+
+The Vault CLI can be used to read, write, and delete data from Vault.
+This data might be raw secrets, it might be configuration for
+a backend, etc. Whatever it is, the interface to read and write data
+to Vault is the same.
+
+To determine what paths can be used to read and write data,
+please use the built-in [help system](/docs/commands/help.html)
+to discover the paths.
+
+## Writing Data
+
+To write data to Vault, you use `vault write`. It is very easy to use:
+
+```
+$ vault write secret/password value=itsasecret
+...
+```
+
+The above writes a value to `secret/password`. As mentioned in the getting
+started guide, multiple values can also be written:
+
+```
+$ vault write secret/password value=itsasecret username=something
+...
+```
+
+For the `secret/` backend, the key/value pairs are arbitrary and can be
+anything. For other backends, they're generally more strict, and the
+help system can tell you what data to send to Vault.
+
+In addition to writing key/value pairs, Vault can write from a variety
+more sources.
+
+#### stdin
+
+`vault write` can read data to write from stdin by using "-" as the value.
+If you use "-" as the entire argument, then Vault expects to read a JSON
+object from stdin. The example below is equivalent to the first example
+above.
+
+```
+$ echo -n '{"value":"itsasecret"}' | vault write secret/password -
+...
+```
+
+You can also add more values in addition to "-" on the command-line.
+Depending on their ordering will determine if they overwrite the values
+from stdin: if they're after the "-" (positionally on the command-line),
+then they will overwrite it, otherwise the values in stdin will overwrite
+the command line values.
+
+In addition to reading full JSON objects, Vault can read just a JSON
+value. The example below is also identical to the previous example.
+
+```
+$ echo -n "itsasecret" | vault write secret/password value=-
+...
+```
+
+#### Files
+
+`vault write` can read data from files as well. The usage is very similar
+to stdin as documented above, but the syntax is `@filename`. Example:
+
+```
+$ cat data.json
+{ "value": "itsasecret" }
+
+$ vault write secret/password @data.json
+...
+```
+
+And, just like stdin, you can also specify just values:
+
+```
+$ cat data.txt
+itsasecret
+
+$ vault write secret/password value=@data.txt
+```
+
+Unlike stdin, you can specify multiple files, repeat files, etc. all
+on the command line. Reading from files is very useful for complex data.
+
+## Reading Data
+
+Data can be read using `vault read`. This command is very simple:
+
+```
+$ vault read secret/password
+Key             Value
+lease_id        secret/password/76c844fb-aeba-a766-0a50-2b907072233a
+lease_duration  2592000
+value           itsasecret
+```
+
+You can use the `-format` flag to get various different formats out
+from the command. Some formats are easier to use in different environments
+than others.
+
+You can also use the `-field` flag to extract an individual field
+from the secret data.
+
+```
+$ vault read -field=value secret/password
+itsasecret
+```
+
diff --git a/website/source/docs/concepts/auth.html.md b/website/source/docs/concepts/auth.html.md
new file mode 100644
index 000000000..873759a83
--- /dev/null
+++ b/website/source/docs/concepts/auth.html.md
@@ -0,0 +1,99 @@
+---
+layout: "docs"
+page_title: "Authentication"
+sidebar_current: "docs-concepts-auth"
+description: |-
+  Before performing any operation with Vault, the connecting client must be authenticated.
+---
+
+# Authentication
+
+Before performing any operation with Vault, the connecting client must be
+_authenticated_. Authentication is the process of verifying a person or
+machine is who they say they are and assigning an identity to them. This
+identity is then used when making requests with Vault.
+
+Authentication in Vault is pluggable via authentication backends. This
+allows you to authenticate with Vault using a method that works best for your
+organization. For example, you can authenticate using GitHub, certs, etc.
+
+## Authentication Backends
+
+There are many authentication backends available for Vault. They
+are enabled using `vault auth-enable`. After they're enabled, you can
+learn more about them using `vault path-help auth/<name>`. For example,
+if you enable GitHub, you can use `vault path-help auth/github` to learn more
+about how to configure it and login.
+
+Multiple authentication backends can be enabled, but only one is required
+to gain authentication. It is not currently possible to force a user through
+multiple authentication backends to gain access.
+
+This allows you to enable human-friendly as well as machine-friendly
+backends at the same time. For example, for humans you might use the
+"github" auth backend, and for machines you might use the "app-id" backend.
+
+## Tokens
+
+There is an [entire page dedicated to tokens](/docs/concepts/tokens.html),
+but it is important to understand that authentication works by verifying
+your identity and then generating a token to associate with that identity.
+
+For example, even though you may authenticate using something like GitHub,
+Vault generates a unique access token for you to use for future requests.
+The CLI automatically attaches this token to requests, but if you're using
+the API you'll have to do this manually.
+
+This token given for authentication with any backend can also be used
+with the full set of token commands, such as creating new sub-tokens,
+revoking tokens, and renewing tokens. This is all covered on the
+[token concepts page](/docs/concepts/tokens.html).
+
+## Authenticating
+
+#### Via the CLI
+
+To authenticate with the CLI, `vault auth` is used. This supports many
+of the built-in authentication methods. For example, with GitHub:
+
+```
+$ vault auth -method=github token=<token>
+...
+```
+
+After authenticating, you will be logged in. The CLI command will also
+output your raw token. This token is used for revocation and renewal.
+As the user logging in, the primary use case of the token is renewal,
+covered below in the "Auth Leases" section.
+
+To determine what variables are needed for an authentication method,
+supply the `-method` flag without any additional arguments and help
+will be shown.
+
+If you're using a method that isn't supported via the CLI, then the API
+must be used.
+
+#### Via the API
+
+API authentication is generally used for machine authentication. Each
+auth backend implements is own login endpoint. Use the `vault path-help`
+mechanism to find the proper endpoint.
+
+For example, the GitHub login endpoint is located at `auth/github/login`.
+And to determine the arguments needed, `vault path-help auth/github/login` can
+be used.
+
+## Auth Leases
+
+Just like secrets, identities have
+[leases](/docs/concepts/lease.html) associated with them. This means that
+you must reauthenticate after the given lease period to continue accessing
+Vault.
+
+To set the lease associated with an identity, reference the help for
+the specific authentication backend in use. It is specific to each backend
+how leasing is implemented.
+
+And just like secrets, identities can be renewed without having to
+completely reauthenticate. Just use `vault token-renew <token>` with the
+token associated with your identity to renew it.
diff --git a/website/source/docs/concepts/dev-server.html.md b/website/source/docs/concepts/dev-server.html.md
new file mode 100644
index 000000000..b7c35f7a4
--- /dev/null
+++ b/website/source/docs/concepts/dev-server.html.md
@@ -0,0 +1,53 @@
+---
+layout: "docs"
+page_title: "Dev Server Mode"
+sidebar_current: "docs-concepts-devserver"
+description: |-
+  The dev server in Vault can be used for development or to experiment with Vault.
+---
+
+# "Dev" Server Mode
+
+You can start Vault as a server in "dev" mode like so: `vault server -dev`.
+This dev-mode server requires no further setup, and your local `vault` CLI will
+be authenticated to talk to it. This makes it easy to experiment with Vault or
+start a Vault instance for development. Every feature of Vault is available in 
+"dev" mode. The `-dev` flag just short-circuits a lot of setup to insecure 
+defaults.
+
+~> **Warning:** Never, ever, ever run a "dev" mode server in production.
+It is insecure and will lose data on every restart (since it stores data
+in-memory). It is only made for development or experimentation.
+
+## Properties
+
+The properties of the dev server:
+
+  * **Initialized and unsealed** - The server will be automatically initialized
+    and unsealed. You don't need to use `vault unseal`. It is ready for use
+    immediately.
+
+  * **In-memory storage** - All data is stored (encrypted) in-memory. Vault
+    server doesn't require any file permissions.
+
+  * **Bound to local address without TLS** - The server is listening on
+    `127.0.0.1:8200` (the default server address) _without_ TLS.
+
+  * **Automatically Authenticated** - The server stores your root access
+    token so `vault` CLI access is ready to go. If you are accessing Vault
+    via the API, you'll need to authenticate using the token printed out.
+
+  * **Single unseal key** - The server is initialized with a single unseal
+    key. The Vault is already unsealed, but if you want to experiment with
+    seal/unseal, then only the single outputted key is required.
+
+## Use Case
+
+The dev server should be used for experimentation with Vault features, such
+as different authentication backends, secret backends, audit backends, etc.
+If you're new to Vault, you may want to pick up with [Your First 
+Secret](http://vaultproject.io/intro/getting-started/first-secret.html) in 
+our getting started guide.
+
+In addition to experimentation, the dev server is very easy to automate
+for development environments.
diff --git a/website/source/docs/concepts/ha.html.markdown b/website/source/docs/concepts/ha.html.markdown
new file mode 100644
index 000000000..0058aed43
--- /dev/null
+++ b/website/source/docs/concepts/ha.html.markdown
@@ -0,0 +1,42 @@
+---
+layout: "docs"
+page_title: "High Availability"
+sidebar_current: "docs-concepts-ha"
+description: |-
+  Vault can be highly available, allowing you to run multiple Vaults to protect against outages.
+---
+
+# High Availability Mode (HA)
+
+Vault supports multi-server mode for high availability. This mode protects
+against outages by running multiple Vault servers. High availability mode
+is automatically enabled when using a storage backend that supports it.
+
+You can tell if a backend supports high availability mode ("HA") by
+starting the server and seeing if "(HA available)" is outputted next to
+the backend information. If it is, then HA will begin happening automatically.
+
+To be highly available, Vault elects a leader and does request forwarding to
+the leader. Due to this architecture, HA does not enable increased scalability.
+In general, the bottleneck of Vault is the storage backend itself, not
+Vault core. For example: to increase scalability of Vault with Consul, you
+would scale Consul instead of Vault.
+
+In addition to using a backend that supports HA, you have to configure
+Vault with an _advertise address_. This is the address that Vault advertises
+to other Vault servers in the cluster for request forwarding. By default,
+Vault will use the first private IP address it finds, but you can override
+this to any address you want.
+
+## Backend Support
+
+Currently there are several backends that support high availability mode,
+including Consul, ZooKeeper and etcd. These may change over time, and the
+[configuration page](/docs/config/index.html) should be referenced.
+
+The Consul backend is the recommended HA backend, as it is used in production
+by HashiCorp and it's customers with commercial support.
+
+If you're interested in implementing another backend or adding HA support
+to another backend, we'd love your contributions. Adding HA support
+requires implementing the `physical.HABackend` interface for the storage backend.
diff --git a/website/source/docs/concepts/index.html.md b/website/source/docs/concepts/index.html.md
new file mode 100644
index 000000000..37063f5bd
--- /dev/null
+++ b/website/source/docs/concepts/index.html.md
@@ -0,0 +1,16 @@
+---
+layout: "docs"
+page_title: "Basic Concepts"
+sidebar_current: "docs-concepts"
+description: |-
+  Basic concepts that are important to understand for Vault usage.
+---
+
+# Basic Concepts
+
+This section covers some high level basic concepts that are important
+to understand for day to day Vault usage and operation. Every page in
+this section is recommended reading for anyone consuming or operating
+Vault.
+
+Please use the navigation to the left to learn more about a topic.
diff --git a/website/source/docs/concepts/lease.html.md b/website/source/docs/concepts/lease.html.md
new file mode 100644
index 000000000..267190efa
--- /dev/null
+++ b/website/source/docs/concepts/lease.html.md
@@ -0,0 +1,75 @@
+---
+layout: "docs"
+page_title: "Lease, Renew, and Revoke"
+sidebar_current: "docs-concepts-lease"
+description: |-
+  Vault provides a lease with every secret. When this lease is expired, Vault will revoke that secret.
+---
+
+# Lease, Renew, and Revoke
+
+With every secret and authentication token, Vault provides a _lease_:
+an amount of time that Vault promises that the data will be valid for.
+Once the lease is up, Vault can automatically revoke the data, and the
+consumer of the secret can no longer be certain that it is valid.
+
+The benefit should be clear: consumers of secrets need to check in with
+Vault routinely to either renew the lease (if allowed) or request a
+replacement secret. This makes the Vault audit logs more valuable and
+also makes key rolling a lot easier.
+
+All secrets in Vault are required to have a lease. Even if the data is
+meant to be valid for eternity, a lease is required to force the consumer
+to check in routinely.
+
+In addition to renewals, a lease can be _revoked_. When a lease is revoked,
+it invalidates that secret immediately and prevents any further renewals.
+For
+[dynamic secrets](#),
+the secrets themselves are often immediately disabled. For example, with
+the
+[AWS secret backend](/docs/secrets/aws/index.html), the access keys will
+be deleted from AWS the moment a secret is revoked. This renders the access
+keys invalid from that point forward.
+
+Revocation can happen manually via the API or `vault revoke`, or automatically
+by Vault. When a lease is expired, Vault will automatically revoke that
+lease.
+
+## Lease IDs
+
+When reading a secret, such as via `vault read`, Vault always returns
+a `lease_id`. This is the ID used with commands such as `vault renew` and
+`vault revoke` to manage the lease of the secret.
+
+## Lease Durations and Renewal
+
+Along with the lease ID, a _lease duration_ can be read. The lease duration
+is the time in seconds that the lease is valid for. A consumer of this
+secret must renew the lease within that time.
+
+When renewing the lease, the user can request a specific amount of time
+from now to extend the lease. For example: `vault renew my-lease-id 3600`
+would request to extend the lease of "my-lease-id" by 1 hour (3600 seconds).
+
+The requested increment is completely advisory. The backend in charge
+of the secret can choose to completely ignore it. For most secrets, the
+backend does its best to respect the increment, but often limits it to
+ensure renewals every so often.
+
+As a result, the return value of renews should be carefully inspected
+to determine what the new lease is.
+
+## Prefix-based Revocation
+
+In addition to revoking a single secret, operators with proper access
+control can revoke multiple secrets based on their lease ID prefix.
+
+Lease IDs are structured in a way that their prefix is always the path
+where the secret was requested from. This lets you revoke trees of
+secrets. For example, to revoke all AWS access keys, you can do
+`vault revoke -prefix aws/`.
+
+This is very useful if there is an intrusion within a specific system:
+all secrets of a specific backend or a certain configured backend can
+be revoked quickly and easily.
diff --git a/website/source/docs/concepts/policies.html.md b/website/source/docs/concepts/policies.html.md
new file mode 100644
index 000000000..ebe476b68
--- /dev/null
+++ b/website/source/docs/concepts/policies.html.md
@@ -0,0 +1,133 @@
+---
+layout: "docs"
+page_title: "Policies"
+sidebar_current: "docs-concepts-policies"
+description: |-
+  Policies are how authorization is done in Vault, allowing you to restrict which parts of Vault a user can access.
+---
+
+# Access Control Policies
+
+After [authenticating](/docs/concepts/auth.html) with Vault, the
+next step is authorization. This is the process of determining what
+a user is allowed to do. Authorization is unified in Vault in the form
+of _policies_.
+
+Policies are [HCL](https://github.com/hashicorp/hcl) or JSON documents
+that describe what parts of Vault a user is allowed to access. An example
+of a policy is shown below:
+
+```javascript
+path "sys/*" {
+  policy = "deny"
+}
+
+path "secret/*" {
+  policy = "write"
+}
+
+path "secret/foo" {
+  policy = "read"
+}
+
+path "secret/super-secret" {
+  policy = "deny"
+}
+```
+
+Policies use path based matching to apply rules. A policy may be an exact
+match, or might be a glob pattern which uses a prefix. The default policy
+is always deny so if a path isn't explicitly allowed, Vault will reject access to it.
+This works well due to Vault's architecture of being like a filesystem:
+everything has a path associated with it, including the core configuration
+mechanism under "sys".
+
+~> Policy paths are matched using the most specific defined policy. This may
+be an exact match or the longest-prefix match of a glob. This means if you
+define a policy for `"secret/foo*"`, the policy would also match `"secret/foobar"`.
+The glob character is only supported at the end of the path specification.
+
+## Policies
+
+Allowed policies for a path are:
+
+  * `deny` - No access allowed. Highest precedence.
+
+  * `sudo` - Read, write, and root access to a path.
+
+  * `write` - Read, write access to a path.
+
+  * `read` - Read-only access to a path.
+
+The only non-obvious policy is "sudo". Some routes within Vault and mounted
+backends are marked as _root_ paths. Clients aren't allowed to access root
+paths unless they are a root user (have the special policy "root") or
+have access to that path with the "sudo" policy.
+
+For example, modifying the audit log backends is done via root paths.
+Only root or "sudo" privilege users are allowed to do this.
+
+## Root Policy
+
+The "root" policy is a special policy that can not be modified or removed.
+Any user associated with the "root" policy becomes a root user. A root
+user can do _anything_ within Vault.
+
+There always exists at least one root user (associated with the token
+when initializing a new server). After this root user, it is recommended
+to create more strictly controlled users. The original root token should
+be protected accordingly.
+
+## Managing Policies
+
+Policy management can be done via the API or CLI. The CLI commands are
+`vault policies` and `vault policy-write`. Please see the help associated
+with these commands for more information. They are very easy to use.
+
+## Associating Policies
+
+To associate a policy with a user, you must consult the documentation for
+the authentication backend you're using.
+
+For tokens, they are associated at creation time with `vault token-create`
+and the `-policy` flags. Child tokens can be associated with a subset of
+a parent's policies. Root users can assign any policies.
+
+There is no way to modify the policies associated with an active
+identity. The identity must be revoked and reauthenticated to receive
+the new policy list.
+
+If an _existing_ policy is modified, the modifications propagate
+to all associated users instantly. The above paragraph is more specifically
+stating that you can't add new or remove policies associated with an
+active identity.
+
+## Changes from 0.1
+
+In Vault versions prior to 0.2, the ACL policy language had a slightly
+different specification and semantics. The current specification requires
+that glob behavior explicitly be specified by adding the `*` character to
+the end of a path. Previously, all paths were glob based matches and no
+exact match could be specified.
+
+The other change is that deny had the lowest precedence. This meant if there
+were two policies being merged (e.g. "ops" and "prod") and they had a conflicting
+policy like:
+
+```
+path "sys/seal" {
+    policy = "deny"
+}
+
+path "sys/seal" {
+    policy = "read"
+}
+```
+
+The merge would previously give the "read" higher precedence. The current
+version of Vault prioritizes the explicit deny, so that the "deny" would
+take precedence.
+
+To make all Vault 0.1 policies compatible with Vault 0.2, the explicit
+glob character must be added to all the path prefixes.
+
diff --git a/website/source/docs/concepts/seal.html.md b/website/source/docs/concepts/seal.html.md
new file mode 100644
index 000000000..e980c3d06
--- /dev/null
+++ b/website/source/docs/concepts/seal.html.md
@@ -0,0 +1,72 @@
+---
+layout: "docs"
+page_title: "Seal/Unseal"
+sidebar_current: "docs-concepts-seal"
+description: |-
+  A Vault must be unsealed before it can access its data. Likewise, it can be sealed to lock it down.
+---
+
+# Seal/Unseal
+
+When a Vault server is started, it starts in a _sealed_ state. In this
+state, Vault is configured to know where and how to access the physical
+storage, but doesn't know how to decrypt any of it.
+
+_Unsealing_ is the process of constructing the master key necessary to
+read the decryption key to decrypt the data, allowing access to the Vault.
+
+Prior to unsealing, almost no operations are possible with Vault. For
+example authentication, managing the mount tables, etc. are all not possible.
+The only possible operations are to unseal the Vault and check the status
+of the unseal.
+
+## Why?
+
+The data stored by Vault is stored encrypted. Vault needs the
+_encryption key_ in order to decrypt the data. The encryption key is
+also stored with the data, but encrypted with another encryption key
+known as the _master key_. The master key isn't stored anywhere.
+
+Therefore, to decrypt the data, Vault must decrypt the encryption key
+which requires the master key. Unsealing is the process of reconstructing
+this master key.
+
+Instead of distributing this master key as a single key to an operator,
+Vault uses an algorithm known as
+[Shamir's Secret Sharing](http://en.wikipedia.org/wiki/Shamir%27s_Secret_Sharing)
+to split the key into shards. A certain threshold of shards is required to
+reconstruct the master key.
+
+This is the _unseal_ process: the shards are added one at a time (in any
+order) until enough shards are present to reconstruct the key and
+decrypt the data.
+
+## Unsealing
+
+The unseal process is done by running `vault unseal` or via the API.
+This process is stateful: each key can be entered via multiple mechanisms
+on multiple computers and it will work. This allows each shard of the master
+key to be on a distinct machine for better security.
+
+Once a Vault is unsealed, it remains unsealed until one of two things happens:
+
+  1. It is resealed via the API (see below).
+
+  2. The server is restarted.
+
+-> **Note:** Unsealing makes the process of automating a Vault install
+difficult. Automated tools can easily install, configure, and start Vault,
+but unsealing it is a very manual process. We have plans in the future to
+make it easier. For the time being, the best method is to manually unseal
+multiple Vault servers in [HA mode](/docs/concepts/ha.html). Use a tool such
+as Consul to make sure you only query Vault servers that are unsealed.
+
+## Sealing
+
+There is also an API to seal the Vault. This will throw away the encryption
+key and require another unseal process to restore it. Sealing only requires
+a single operator with root privileges.
+
+This way, if there is a detected intrusion, the Vault data can be locked
+quickly to try to minimize damages. It can't be accessed again without
+access to the master key shards.
diff --git a/website/source/docs/concepts/tokens.html.md b/website/source/docs/concepts/tokens.html.md
new file mode 100644
index 000000000..8ecbd7690
--- /dev/null
+++ b/website/source/docs/concepts/tokens.html.md
@@ -0,0 +1,58 @@
+---
+layout: "docs"
+page_title: "Tokens"
+sidebar_current: "docs-concepts-tokens"
+description: |-
+  Tokens are a core authentication method in Vault. Child tokens, token-based revocation, and more.
+---
+
+# Tokens
+
+Tokens are the core method for _authentication_ within Vault. Tokens
+can be used directly or [authentication backends](/docs/concepts/auth.html)
+can be used to dynamically generate tokens based on external identities.
+
+If you've gone through the getting started guide, you probably noticed that
+`vault server -dev` (or `vault init` for a non-dev server) outputs an
+initial "root token." This is the first method of authentication for Vault.
+It is also the only authentication backend that cannot be disabled.
+
+As stated in the [authentication concepts](/docs/concepts/auth.html),
+all external authentication mechanisms such as GitHub map down to dynamically
+created tokens. These tokens have all the same properties as a normal
+manually created token.
+
+On this page, we'll show you how to create and manage tokens.
+
+## Token Creation
+
+Tokens are created via the API or using `vault token-create` from the CLI.
+This will create a new token that is a child of the currently authenticated
+token. As a child, the new token will automatically be revoked if the parent
+is revoked.
+
+If you're logged in as root, you can create an _orphan_ token by
+specifying the `-orphan` flag. An orphan token has no parent, and therefore
+when your token is revoked, it will not revoke the orphan.
+
+Metadata associated with the token with `-metadata` is used to annotate
+the token with information that is added to the audit log.
+
+Finally, the `-policy` flag can be used to set the policies associated
+with the token. Learn more about policies on the
+[policies concepts](/docs/concepts/policies.html) page.
+
+## Token Leases
+
+Every token has a lease associated with it. These leases behave in much
+the same way as [leases for secrets](/docs/concepts/lease.html). After
+the lease period is up, the token will no longer function. In addition
+to no longer functioning, Vault will revoke it.
+
+In order to avoid your token being revoked, the `vault token-renew`
+command should be used to renew the lease on the token periodically.
+
+After a token is revoked, all of the secrets in use by that token will
+also be revoked. Therefore, if a user requests AWS access keys, for example,
+then after the token expires the AWS access keys will also be expired even
+if they had remaining lease time.
diff --git a/website/source/docs/config/index.html.md b/website/source/docs/config/index.html.md
new file mode 100644
index 000000000..a9a5a81ef
--- /dev/null
+++ b/website/source/docs/config/index.html.md
@@ -0,0 +1,242 @@
+---
+layout: "docs"
+page_title: "Server Configuration"
+sidebar_current: "docs-config"
+description: |-
+  Vault server configuration reference.
+---
+
+# Server Configuration
+
+Outside of development mode, Vault servers are configured using a file.
+The format of this file is [HCL](https://github.com/hashicorp/hcl) or JSON.
+An example configuration is shown below:
+
+```javascript
+backend "consul" {
+  address = "127.0.0.1:8500"
+  path = "vault"
+}
+
+listener "tcp" {
+  address = "127.0.0.1:8200"
+  tls_disable = 1
+}
+
+telemetry {
+  statsite_address = "127.0.0.1:8125"
+  disable_hostname = true
+}
+```
+
+After the configuration is written, use the `-config` flag with `vault server`
+to specify where the configuration is.
+
+## Reference
+
+* `backend` (required) - Configures the storage backend where Vault data
+  is stored. There are multiple options available for storage backends,
+  and they're documented below.
+
+* `listener` (required) - Configures how Vault is listening for API requests.
+  "tcp" is currently the only option available. A full reference for the
+   inner syntax is below.
+
+* `disable_mlock` (optional) - A boolean. If true, this will disable the
+  server from executing the `mlock` syscall to prevent memory from being
+  swapped to disk. This is not recommended in production (see below).
+
+* `telemetry` (optional)  - Configures the telemetry reporting system
+  (see below).
+
+* `default_lease_duration` (optional) - Configures the default lease
+  duration for tokens and secrets, specified in hours. Default value
+  is 30 days. This value cannot be larger than `max_lease_duration`.
+
+* `max_lease_duration` (optional) - Configures the maximum possible
+  lease duration for tokens and secrets, specified in hours. Default
+  value is 30 days.
+
+In production, you should only consider setting the `disable_mlock` option
+on Linux systems that only use encrypted swap or do not use swap at all.
+Vault does not currently support memory locking on Mac OS X and Windows
+and so the feature is automatically disabled on those platforms.  To give
+the Vault executable access to the `mlock` syscall on Linux systems:
+
+```shell
+sudo setcap cap_ipc_lock=+ep $(readlink -f $(which vault))
+```
+
+## Backend Reference
+
+For the `backend` section, the supported backends are shown below.
+Vault requires that the backend itself will be responsible for backups,
+durability, etc.
+
+  * `consul` - Store data within [Consul](http://www.consul.io). This
+      backend supports HA. It is the most recommended backend for Vault
+      and has been shown to work at high scale under heavy load.
+
+  * `etcd` - Store data within [etcd](https://coreos.com/etcd/).
+      This backend supports HA.
+
+  * `zookeeper` - Store data within [Zookeeper](https://zookeeper.apache.org/).
+      This backend supports HA.
+
+  * `s3` - Store data within an S3 bucket [S3](http://aws.amazon.com/s3/).
+      This backend does not support HA.
+
+  * `mysql` - Store data within MySQL. This backend does not support HA.
+
+  * `inmem` - Store data in-memory. This is only really useful for
+      development and experimentation. Data is lost whenever Vault is
+      restarted.
+
+  * `file` - Store data on the filesystem using a directory structure.
+      This backend does not support HA.
+
+#### Common Backend Options
+
+All backends support the following options:
+
+  * `advertise_addr` (optional) - For backends that support HA, this
+      is the address to advertise to other Vault servers in the cluster
+      for request forwarding. Most HA backends will attempt to determine
+      the advertise address if not provided.
+
+#### Backend Reference: Consul
+
+For Consul, the following options are supported:
+
+  * `path` (optional) - The path within Consul where data will be stored.
+      Defaults to "vault/".
+
+  * `address` (optional) - The address of the Consul agent to talk to.
+      Defaults to the local agent address, if available.
+
+  * `scheme` (optional) - "http" or "https" for talking to Consul.
+
+  * `datacenter` (optional) - The datacenter within Consul to write to.
+      This defaults to the local datacenter.
+
+  * `token` (optional) - An access token to use to write data to Consul.
+
+  * `tls_skip_verify` (optional) - If non-empty, then TLS host verification
+      will be disabled for Consul communication.
+      Defaults to false.
+
+  The following settings should be set according to your [Consul encryption settings](https://www.consul.io/docs/agent/encryption.html):
+
+  * `tls_ca_file` (optional) - The path to the CA certificate used for Consul communication.
+      Defaults to system bundle if not specified.
+      Set accordingly to the [ca_file](https://www.consul.io/docs/agent/options.html#ca_file) setting in Consul.
+
+  * `tls_cert_file` (optional) - The path to the certificate for Consul communication.
+      Set accordingly to the [cert_file](https://www.consul.io/docs/agent/options.html#cert_file) setting in Consul.
+
+  * `tls_key_file` (optional) - The path to the private key for Consul communication.
+      Set accordingly to the [key_file](https://www.consul.io/docs/agent/options.html#key_file) setting in Consul.
+
+#### Backend Reference: Zookeeper
+
+For Zookeeper, the following options are supported:
+
+  * `path` (optional) - The path within Zookeeper where data will be stored.
+      Defaults to "vault/".
+
+  * `address` (optional) - The address(es) of the Zookeeper instance(s) to talk to.
+      Can be comma separated list (host:port) of many Zookeeper instances.
+      Defaults to "localhost:2181" if not specified.
+
+#### Backend Reference: etcd
+
+For etcd, the following options are supported:
+
+  * `path` (optional) - The path within etcd where data will be stored.
+      Defaults to "vault/".
+
+  * `address` (optional) - The address(es) of the etcd instance(s) to talk to.
+      Can be comma separated list (protocol://host:port) of many etcd instances.
+      Defaults to "http://localhost:4001" if not specified.
+
+#### Backend Reference: S3
+
+For S3, the following options are supported:
+
+  * `bucket` (required) - The name of the S3 bucket to use.
+
+  * `access_key` - (required) The AWS access key. It must be provided, but it can also be sourced from the AWS_ACCESS_KEY_ID environment variable.
+
+  * `secret_key` - (required) The AWS secret key. It must be provided, but it can also be sourced from the AWS_SECRET_ACCESS_KEY environment variable.
+
+  * `session_token` - (optional) The AWS session_token. It can also be sourced from the AWS_SESSION_TOKEN environment variable.
+
+  * `region` (optional) - The AWS region. It can be sourced from the AWS_DEFAULT_REGION environment variable and will default to "us-east-1" if not specified.
+
+#### Backend Reference: MySQL
+
+The MySQL backend has the following options:
+
+  * `username` (required) - The MySQL username to connect with.
+
+  * `password` (required) - The MySQL password to connect with.
+
+  * `address` (optional) - The address of the MySQL host. Defaults to
+    "127.0.0.1:3306.
+
+  * `database` (optional) - The name of the database to use. Defaults to "vault".
+
+  * `table` (optional) - The name of the table to use. Defaults to "vault".
+
+  * `tls_ca_file` (optional) - The path to the CA certificate to connect using TLS
+
+#### Backend Reference: Inmem
+
+The in-memory backend has no configuration options.
+
+#### Backend Reference: File
+
+The file backend has the following options:
+
+  * `path` (required) - The path on disk to a directory where the
+      data will be stored.
+
+## Listener Reference
+
+For the `listener` section, the only supported listener currently
+is "tcp". Regardless of future plans, this is the recommended listener,
+since it allows for HA mode.
+
+The supported options are:
+
+  * `address` (optional) - The address to bind to for listening. This
+      defaults to "127.0.0.1:8200".
+
+  * `tls_disable` (optional) - If non-empty, then TLS will be disabled.
+      This is an opt-in; Vault assumes by default that TLS will be used.
+
+  * `tls_cert_file` (required unless disabled) - The path to the certificate
+      for TLS.
+
+  * `tls_key_file` (required unless disabled) - The path to the private key
+      for the certificate.
+
+  * `tls_min_version` (optional) - **(Vault > 0.2)** If provided, specifies
+      the minimum supported version of TLS. Accepted values are "tls10", "tls11"
+      or "tls12". This defaults to "tls12". WARNING: TLS 1.1 and lower
+      are generally considered less secure; avoid using these if
+      possible.
+
+## Telemetry Reference
+
+For the `telemetry` section, there is no resource name. All configuration
+is within the object itself.
+
+* `statsite_address` (optional) - An address to a [Statsite](https://github.com/armon/statsite)
+  instances for metrics. This is highly recommended for production usage.
+
+* `statsd_address` (optional) - This is the same as `statsite_address` but
+  for StatsD.
+
+* `disable_hostname` (optional) - Whether or not to prepend runtime telemetry
+  with the machines hostname. This is a global option. Defaults to false.
diff --git a/website/source/docs/http/index.html.md b/website/source/docs/http/index.html.md
new file mode 100644
index 000000000..282eebf54
--- /dev/null
+++ b/website/source/docs/http/index.html.md
@@ -0,0 +1,148 @@
+---
+layout: "http"
+page_title: "HTTP API"
+sidebar_current: "docs-http-overview"
+description: |-
+  Vault has an HTTP API that can be used to control every aspect of Vault.
+---
+
+# HTTP API
+
+The Vault HTTP API gives you full access to Vault via HTTP. Every
+aspect of Vault can be controlled via this API. The Vault CLI uses
+the HTTP API to access Vault.
+
+## Version Prefix
+
+All API routes are prefixed with `/v1/`.
+
+This documentation is only for the v1 API.
+
+~> **Backwards compatibility:** At the current version, Vault does
+not yet promise backwards compatibility even with the v1 prefix. We'll
+remove this warning when this policy changes. We expect we'll reach API
+stability by Vault 0.3.
+
+## Transport
+
+The API is expected to be accessed over a TLS connection at
+all times, with a valid certificate that is verified by a well
+behaved client. It is possible to disable TLS verification for
+listeners, however, so API clients should expect to have to do both
+depending on user settings.
+
+## Authentication
+
+Once the Vault is unsealed, every other operation requires
+a _client token_. A user may have a client token explicitly.
+The client token must be sent as the `token` cookie or the
+`X-Vault-Token` HTTP header.
+
+Otherwise, a client token can be retrieved via
+[authentication backends](/docs/auth/index.html).
+
+Each authentication backend will have one or more unauthenticated
+login endpoints. These endpoints can be reached without any authentication,
+and are used for authentication itself. These endpoints are specific
+to each authentication backend.
+
+Login endpoints for authentication backends that generate an identity
+will be sent down with a `Set-Cookie` header as well as via JSON. If you have a
+well-behaved HTTP client, then authentication information will
+automatically be saved and sent to the Vault API.
+
+## Reading and Writing Secrets
+
+Reading a secret via the HTTP API is done by issuing a GET using the
+following URL:
+
+```text
+/v1/secret/foo
+```
+
+This maps to `secret/foo` where `foo` is the key in the `secret/` backend/
+
+Here is an example of reading a secret using cURL:
+
+```shell
+curl \
+  -H "X-Vault-Token: f3b09679-3001-009d-2b80-9c306ab81aa6" \
+  -X GET \
+   http://127.0.0.1:8200/v1/secret/foo
+```
+
+To write a secret, issue a POST on the following URL:
+
+```text
+/v1/secret/foo
+```
+
+with a JSON body like:
+
+```javascript
+{
+  "value": "bar"
+}
+```
+
+Here is an example of writing a secret using cURL:
+
+```shell
+curl \
+  -H "X-Vault-Token: f3b09679-3001-009d-2b80-9c306ab81aa6" \
+  -H "Content-Type: application/json" \
+  -X POST \
+  -d '{"value":"bar"}' \
+  http://127.0.0.1:8200/v1/secret/baz
+```
+
+For more examples, please look at the Vault API client.
+
+## Help
+
+To retrieve the help for any API within Vault, including mounted
+backends, credential providers, etc. then append `?help=1` to any
+URL. If you have valid permission to access the path, then the help text
+will be returned with the following structure:
+
+```javascript
+{
+  "help": "help text"
+}
+```
+
+## Error Response
+
+A common JSON structure is always returned to return errors:
+
+```javascript
+{
+  "errors": [
+    "message",
+    "another message"
+  ]
+}
+```
+
+This structure will be sent down for any HTTP status greater than
+or equal to 400.
+
+## HTTP Status Codes
+
+The following HTTP status codes are used throughout the API.
+
+- `200` - Success with data.
+- `204` - Success, no data returned.
+- `400` - Invalid request, missing or invalid data. See the
+   "validation" section for more details on the error response.
+- `401` - Unauthorized, your authentication details are either
+   incorrect or you don't have access to this feature.
+- `404` - Invalid path. This can both mean that the path truly
+   doesn't exist or that you don't have permission to view a
+   specific path. We use 404 in some cases to avoid state leakage.
+- `429` - Rate limit exceeded. Try again after waiting some period
+   of time.
+- `500` - Internal server error. An internal error has occurred,
+   try again later. If the error persists, report a bug.
+- `503` - Vault is down for maintenance or is currently sealed.
+   Try again later.
diff --git a/website/source/docs/http/libraries.html.md b/website/source/docs/http/libraries.html.md
new file mode 100644
index 000000000..26ed42b19
--- /dev/null
+++ b/website/source/docs/http/libraries.html.md
@@ -0,0 +1,29 @@
+---
+layout: "http"
+page_title: "HTTP API: Libraries"
+sidebar_current: "docs-http-libraries"
+description: |-
+  List of official and community contributed libraries for interacting with the Vault HTTP API.
+---
+
+# Libraries
+
+The programming libraries listed on this page can be used to consume the API more conveniently.
+Some are officially maintained while others are provided by the community.
+
+## Go
+
+* [Vault Go Client](https://github.com/hashicorp/vault/tree/master/api) (official)
+
+## Ruby
+
+* [Vault Ruby Client](https://github.com/hashicorp/vault-ruby) (official)
+
+## Python
+
+* [HVAC](https://github.com/ianunruh/hvac)
+
+## Node.js
+
+* [node-vault](https://github.com/kr1sp1n/node-vault)
+* [vaulted](https://github.com/chiefy/vaulted)
diff --git a/website/source/docs/http/sys-audit.html.md b/website/source/docs/http/sys-audit.html.md
new file mode 100644
index 000000000..7040e2004
--- /dev/null
+++ b/website/source/docs/http/sys-audit.html.md
@@ -0,0 +1,108 @@
+---
+layout: "http"
+page_title: "HTTP API: /sys/audit"
+sidebar_current: "docs-http-audits-audits"
+description: |-
+  The `/sys/audit` endpoint is used to enable and disable audit backends.
+---
+
+# /sys/audit
+
+## GET
+
+<dl>
+  <dt>Description</dt>
+  <dd>
+    Lists all the available policies.
+  </dd>
+
+  <dt>Method</dt>
+  <dd>GET</dd>
+
+  <dt>Parameters</dt>
+  <dd>
+    None
+  </dd>
+
+  <dt>Returns</dt>
+  <dd>
+
+    ```javascript
+    {
+      "file": {
+        "type: "file",
+        "description: "Store logs in a file",
+        "options": {
+          "path": "/var/log/file"
+        }
+      }
+    }
+    ```
+
+  </dd>
+</dl>
+
+## PUT
+
+<dl>
+  <dt>Description</dt>
+  <dd>
+    Enable an audit backend.
+  </dd>
+
+  <dt>Method</dt>
+  <dd>PUT</dd>
+
+  <dt>URL</dt>
+  <dd>`/sys/audit/<name>`</dd>
+
+  <dt>Parameters</dt>
+  <dd>
+    <ul>
+      <li>
+        <span class="param">type</span>
+        <span class="param-flags">required</span>
+        The type of the audit backend.
+      </li>
+      <li>
+        <span class="param">description</span>
+        <span class="param-flags">optional</span>
+        A description of the audit backend for operators.
+      </li>
+      <li>
+        <span class="param">options</span>
+        <span class="param-flags">optional</span>
+        An object of options to configure the backend. This is
+        dependent on the backend type. Please consult the documentation
+        for the backend type you intend to use.
+      </li>
+    </ul>
+  </dd>
+
+  <dt>Returns</dt>
+  <dd>`204` response code.
+  </dd>
+</dl>
+
+## DELETE
+
+<dl>
+  <dt>Description</dt>
+  <dd>
+    Disable the given audit backend.
+  </dd>
+
+  <dt>Method</dt>
+  <dd>DELETE</dd>
+
+  <dt>URL</dt>
+  <dd>`/sys/audit/<name>`</dd>
+
+  <dt>Parameters</dt>
+  <dd>None
+  </dd>
+
+  <dt>Returns</dt>
+  <dd>`204` response code.
+  </dd>
+</dl>
diff --git a/website/source/docs/http/sys-auth.html.md b/website/source/docs/http/sys-auth.html.md
new file mode 100644
index 000000000..777095d44
--- /dev/null
+++ b/website/source/docs/http/sys-auth.html.md
@@ -0,0 +1,102 @@
+---
+layout: "http"
+page_title: "HTTP API: /sys/auth"
+sidebar_current: "docs-http-auth-auth"
+description: |-
+  The `/sys/auth` endpoint is used to manage auth backends in Vault.
+---
+
+# /sys/auth
+
+## GET
+
+<dl>
+  <dt>Description</dt>
+  <dd>
+    Lists all the enabled auth backends.
+  </dd>
+
+  <dt>Method</dt>
+  <dd>GET</dd>
+
+  <dt>Parameters</dt>
+  <dd>
+    None
+  </dd>
+
+  <dt>Returns</dt>
+  <dd>
+
+    ```javascript
+    {
+      "github": {
+        "type": "github",
+        "description": "GitHub auth"
+      }
+    }
+    ```
+
+  </dd>
+</dl>
+
+## POST
+
+<dl>
+  <dt>Description</dt>
+  <dd>
+    Enable a new auth backend. The auth backend can be accessed
+    and configured via the mount point specified in the URL. This
+    mount point will be exposed under the `auth` prefix. For example,
+    enabling with the `/sys/auth/foo` URL will make the backend
+    available at `/auth/foo`.
+  </dd>
+
+  <dt>Method</dt>
+  <dd>POST</dd>
+
+  <dt>URL</dt>
+  <dd>`/sys/auth/<mount point>`</dd>
+
+  <dt>Parameters</dt>
+  <dd>
+    <ul>
+      <li>
+        <span class="param">type</span>
+        <span class="param-flags">required</span>
+        The name of the auth backend type, such as "github"
+      </li>
+      <li>
+        <span class="param">description</span>
+        <span class="param-flags">optional</span>
+        A human-friendly description of the auth backend.
+      </li>
+    </ul>
+  </dd>
+
+  <dt>Returns</dt>
+  <dd>`204` response code.
+  </dd>
+</dl>
+
+## DELETE
+
+<dl>
+  <dt>Description</dt>
+  <dd>
+    Disable the auth backend at the given mount point.
+  </dd>
+
+  <dt>Method</dt>
+  <dd>DELETE</dd>
+
+  <dt>URL</dt>
+  <dd>`/sys/auth/<mount point>`</dd>
+
+  <dt>Parameters</dt>
+  <dd>None
+  </dd>
+
+  <dt>Returns</dt>
+  <dd>`204` response code.
+  </dd>
+</dl>
diff --git a/website/source/docs/http/sys-health.html.md b/website/source/docs/http/sys-health.html.md
new file mode 100644
index 000000000..80e2d2b81
--- /dev/null
+++ b/website/source/docs/http/sys-health.html.md
@@ -0,0 +1,50 @@
+---
+layout: "http"
+page_title: "HTTP API: /sys/health"
+sidebar_current: "docs-http-debug-health"
+description: |-
+  The '/sys/health' endpoint is used to check the health status of Vault.
+---
+
+# /sys/health
+
+<dl>
+	<dt>Description</dt>
+	<dd>
+		Returns the health status of Vault. This matches the semantics of a Consul HTTP health
+        check and provides a simple way to monitor the health of a Vault instance.
+	</dd>
+
+	<dt>Method</dt>
+	<dd>GET</dd>
+
+	<dt>Parameters</dt>
+	<dd>
+        <ul>
+          <li>
+            <span class="param">standbyok</span>
+            <span class="param-flags">optional</span>
+            A query parameter provided to indicate that being a standby should
+            still return a 200 status code instead of the standard 429 status code.
+          </li>
+        </ul>
+	</dd>
+
+	<dt>Returns</dt>
+	<dd>
+
+```
+{
+    "initialized": true,
+    "sealed": false,
+    "standby": false
+}
+```
+
+    Status Codes:
+
+ * `200` if initialized, unsealed and active.
+ * `429` if unsealed and standby.
+ * `500` if not initialized or sealed.
+	</dd>
+</dl>
diff --git a/website/source/docs/http/sys-init.html.md b/website/source/docs/http/sys-init.html.md
new file mode 100644
index 000000000..6b8695f92
--- /dev/null
+++ b/website/source/docs/http/sys-init.html.md
@@ -0,0 +1,78 @@
+---
+layout: "http"
+page_title: "HTTP API: /sys/init"
+sidebar_current: "docs-http-sys-init"
+description: |-
+  The '/sys/init' endpoint is used to initialize a new Vault.
+---
+
+# /sys/init
+
+## GET
+
+<dl>
+  <dt>Description</dt>
+  <dd>
+    Return the initialization status of a Vault.
+  </dd>
+
+  <dt>Method</dt>
+  <dd>GET</dd>
+
+  <dt>Parameters</dt>
+  <dd>None</dd>
+
+  <dt>Returns</dt>
+  <dd>
+
+    ```javascript
+    {
+      "initialize": true
+    }
+    ```
+
+  </dd>
+</dl>
+
+## PUT
+
+<dl>
+  <dt>Description</dt>
+  <dd>
+    Initializes a new Vault. The Vault must've not been previously
+    initialized.
+  </dd>
+
+  <dt>Method</dt>
+  <dd>PUT</dd>
+
+  <dt>Parameters</dt>
+  <dd>
+    <ul>
+      <li>
+        <span class="param">secret_shares</span>
+        <span class="param-flags">required</span>
+        The number of shares to split the master key into.
+      </li>
+      <li>
+        <span class="param">secret_threshold</span>
+        <span class="param-flags">required</span>
+        The number of shares required to reconstruct the master key.
+        This must be less than or equal to <code>secret_shares</code>.
+      </li>
+    </ul>
+  </dd>
+
+  <dt>Returns</dt>
+  <dd>
+    A JSON-encoded object including the master keys and initial root token:
+
+    ```javascript
+    {
+      "keys": ["one", "two", "three"],
+      "root_token": "foo"
+    }
+    ```
+
+  </dd>
+</dl>
diff --git a/website/source/docs/http/sys-key-status.html.md b/website/source/docs/http/sys-key-status.html.md
new file mode 100644
index 000000000..74d3ffde2
--- /dev/null
+++ b/website/source/docs/http/sys-key-status.html.md
@@ -0,0 +1,38 @@
+---
+layout: "http"
+page_title: "HTTP API: /sys/key-status"
+sidebar_current: "docs-http-rotate-key-status"
+description: |-
+  The '/sys/key-status' endpoint is used to query info about the current encryption key of Vault.
+---
+
+# /sys/key-status
+
+<dl>
+  <dt>Description</dt>
+  <dd>
+    Returns information about the current encryption key used by Vault.
+  </dd>
+
+  <dt>Method</dt>
+  <dd>GET</dd>
+
+  <dt>Parameters</dt>
+  <dd>
+    None
+  </dd>
+
+  <dt>Returns</dt>
+  <dd>
+    The "term" parameter is the sequential key number, and "install_time" is the time that
+    encryption key was installed.
+
+    ```javascript
+    {
+      "term": 3,
+      "install_time": "2015-05-29T14:50:46.223692553-07:00"
+    }
+    ```
+
+  </dd>
+</dl>
diff --git a/website/source/docs/http/sys-leader.html.md b/website/source/docs/http/sys-leader.html.md
new file mode 100644
index 000000000..273ac3102
--- /dev/null
+++ b/website/source/docs/http/sys-leader.html.md
@@ -0,0 +1,37 @@
+---
+layout: "http"
+page_title: "HTTP API: /sys/leader"
+sidebar_current: "docs-http-ha-leader"
+description: |-
+  The '/sys/leader' endpoint is used to check the high availability status and current leader of Vault.
+---
+
+# /sys/leader
+
+<dl>
+  <dt>Description</dt>
+  <dd>
+    Returns the high availability status and current leader instance of Vault.
+  </dd>
+
+  <dt>Method</dt>
+  <dd>GET</dd>
+
+  <dt>Parameters</dt>
+  <dd>
+    None
+  </dd>
+
+  <dt>Returns</dt>
+  <dd>
+
+    ```javascript
+    {
+      "ha_enabled": true,
+      "is_self": false,
+      "leader_address": "https://127.0.0.1:8200/"
+    }
+    ```
+
+  </dd>
+</dl>
diff --git a/website/source/docs/http/sys-mounts.html.md b/website/source/docs/http/sys-mounts.html.md
new file mode 100644
index 000000000..0bdb4f9cd
--- /dev/null
+++ b/website/source/docs/http/sys-mounts.html.md
@@ -0,0 +1,103 @@
+---
+layout: "http"
+page_title: "HTTP API: /sys/mounts"
+sidebar_current: "docs-http-mounts-mounts"
+description: |-
+  The '/sys/mounts' endpoint is used manage secret backends in Vault.
+---
+
+# /sys/mounts
+
+## GET
+
+<dl>
+  <dt>Description</dt>
+  <dd>
+    Lists all the mounted secret backends.
+  </dd>
+
+  <dt>Method</dt>
+  <dd>GET</dd>
+
+  <dt>Parameters</dt>
+  <dd>
+    None
+  </dd>
+
+  <dt>Returns</dt>
+  <dd>
+
+    ```javascript
+    {
+      "aws": {
+        "type": "aws",
+        "description": "AWS keys"
+      },
+
+      "sys": {
+        "type": "system",
+        "description": "system endpoint"
+      }
+    }
+    ```
+
+  </dd>
+</dl>
+
+## POST
+
+<dl>
+  <dt>Description</dt>
+  <dd>
+    Mount a new secret backend to the mount point in the URL.
+  </dd>
+
+  <dt>Method</dt>
+  <dd>POST</dd>
+
+  <dt>URL</dt>
+  <dd>`/sys/mounts/<mount point>`</dd>
+
+  <dt>Parameters</dt>
+  <dd>
+    <ul>
+      <li>
+        <span class="param">type</span>
+        <span class="param-flags">required</span>
+        The name of the backend type, such as "aws"
+      </li>
+      <li>
+        <span class="param">description</span>
+        <span class="param-flags">optional</span>
+        A human-friendly description of the mount.
+      </li>
+    </ul>
+  </dd>
+
+  <dt>Returns</dt>
+  <dd>`204` response code.
+  </dd>
+</dl>
+
+## DELETE
+
+<dl>
+  <dt>Description</dt>
+  <dd>
+    Unmount the mount point specified in the URL.
+  </dd>
+
+  <dt>Method</dt>
+  <dd>DELETE</dd>
+
+  <dt>URL</dt>
+  <dd>`/sys/mounts/<mount point>`</dd>
+
+  <dt>Parameters</dt>
+  <dd>None
+  </dd>
+
+  <dt>Returns</dt>
+  <dd>`204` response code.
+  </dd>
+</dl>
diff --git a/website/source/docs/http/sys-policy.html.md b/website/source/docs/http/sys-policy.html.md
new file mode 100644
index 000000000..e29359383
--- /dev/null
+++ b/website/source/docs/http/sys-policy.html.md
@@ -0,0 +1,92 @@
+---
+layout: "http"
+page_title: "HTTP API: /sys/policy"
+sidebar_current: "docs-http-auth-policy"
+description: |-
+  The `/sys/policy` endpoint is used to manage ACL policies in Vault.
+---
+
+# /sys/policy
+
+## GET
+
+<dl>
+  <dt>Description</dt>
+  <dd>
+    Lists all the available policies.
+  </dd>
+
+  <dt>Method</dt>
+  <dd>GET</dd>
+
+  <dt>Parameters</dt>
+  <dd>
+    None
+  </dd>
+
+  <dt>Returns</dt>
+  <dd>
+
+    ```javascript
+    {
+      "policies": ["root", "deploy"]
+    }
+    ```
+
+  </dd>
+</dl>
+
+## PUT
+
+<dl>
+  <dt>Description</dt>
+  <dd>
+    Add or update a policy. Once a policy is updated, it takes effect
+    immediately to all associated users.
+  </dd>
+
+  <dt>Method</dt>
+  <dd>PUT</dd>
+
+  <dt>URL</dt>
+  <dd>`/sys/policy/<name>`</dd>
+
+  <dt>Parameters</dt>
+  <dd>
+    <ul>
+      <li>
+        <span class="param">rules</span>
+        <span class="param-flags">required</span>
+        The policy document.
+      </li>
+    </ul>
+  </dd>
+
+  <dt>Returns</dt>
+  <dd>`204` response code.
+  </dd>
+</dl>
+
+## DELETE
+
+<dl>
+  <dt>Description</dt>
+  <dd>
+    Delete the policy with the given name. This will immediately
+    affect all associated users.
+  </dd>
+
+  <dt>Method</dt>
+  <dd>DELETE</dd>
+
+  <dt>URL</dt>
+  <dd>`/sys/policy/<name>`</dd>
+
+  <dt>Parameters</dt>
+  <dd>None
+  </dd>
+
+  <dt>Returns</dt>
+  <dd>`204` response code.
+  </dd>
+</dl>
diff --git a/website/source/docs/http/sys-raw.html.md b/website/source/docs/http/sys-raw.html.md
new file mode 100644
index 000000000..2ce1a206f
--- /dev/null
+++ b/website/source/docs/http/sys-raw.html.md
@@ -0,0 +1,96 @@
+---
+layout: "http"
+page_title: "HTTP API: /sys/raw"
+sidebar_current: "docs-http-debug-raw"
+description: |-
+  The `/sys/raw` endpoint is access the raw underlying store in Vault.
+---
+
+# /sys/raw
+
+## GET
+
+<dl>
+  <dt>Description</dt>
+  <dd>
+      Reads the value of the key at the given path. This is the raw path in the
+        storage backend and not the logical path that is exposed via the mount system.
+  </dd>
+
+  <dt>Method</dt>
+  <dd>GET</dd>
+
+  <dt>URL</dt>
+  <dd>`/sys/raw/<path>`</dd>
+
+  <dt>Parameters</dt>
+  <dd>
+    None
+  </dd>
+
+  <dt>Returns</dt>
+  <dd>
+
+    ```javascript
+    {
+      "value": "{'foo':'bar'}"
+    }
+    ```
+
+  </dd>
+</dl>
+
+## PUT
+
+<dl>
+  <dt>Description</dt>
+  <dd>
+      Update the value of the key at the given path. This is the raw path in the
+        storage backend and not the logical path that is exposed via the mount system.
+  </dd>
+
+  <dt>Method</dt>
+  <dd>PUT</dd>
+
+  <dt>URL</dt>
+  <dd>`/sys/raw/<path>`</dd>
+
+  <dt>Parameters</dt>
+  <dd>
+    <ul>
+      <li>
+        <span class="param">value</span>
+        <span class="param-flags">required</span>
+        The value of the key.
+      </li>
+    </ul>
+  </dd>
+
+  <dt>Returns</dt>
+  <dd>`204` response code.
+  </dd>
+</dl>
+
+## DELETE
+
+<dl>
+  <dt>Description</dt>
+  <dd>
+    Delete the key with given path. This is the raw path in the
+        storage backend and not the logical path that is exposed via the mount system.
+  </dd>
+
+  <dt>Method</dt>
+  <dd>DELETE</dd>
+
+  <dt>URL</dt>
+  <dd>`/sys/raw/<path>`</dd>
+
+  <dt>Parameters</dt>
+  <dd>None
+  </dd>
+
+  <dt>Returns</dt>
+  <dd>`204` response code.
+  </dd>
+</dl>
diff --git a/website/source/docs/http/sys-rekey.html.md b/website/source/docs/http/sys-rekey.html.md
new file mode 100644
index 000000000..cd1349a61
--- /dev/null
+++ b/website/source/docs/http/sys-rekey.html.md
@@ -0,0 +1,155 @@
+---
+layout: "http"
+page_title: "HTTP API: /sys/rekey/"
+sidebar_current: "docs-http-rotate-rekey"
+description: |-
+  The `/sys/rekey/` endpoints are used to rekey the unseal keys for Vault.
+---
+
+# /sys/rekey/init
+
+## GET
+
+<dl>
+  <dt>Description</dt>
+  <dd>
+      Reads the configuration and progress of the current rekey attempt.
+  </dd>
+
+  <dt>Method</dt>
+  <dd>GET</dd>
+
+  <dt>URL</dt>
+  <dd>`/sys/rekey/init`</dd>
+
+  <dt>Parameters</dt>
+  <dd>
+    None
+  </dd>
+
+  <dt>Returns</dt>
+  <dd>
+    If a rekey is started, then "n" is the new shares to generate and "t" is
+    the threshold required for the new shares. The "progress" is how many unseal
+    keys have been provided for this rekey, where "required" must be reached to
+    complete.
+
+    ```javascript
+    {
+      "started": true,
+      "t": 3,
+      "n": 5,
+      "progress": 1,
+      "required": 3
+    }
+    ```
+
+  </dd>
+</dl>
+
+## PUT
+
+<dl>
+  <dt>Description</dt>
+  <dd>
+    Initializes a new rekey attempt. Only a single rekey attempt can take place
+    at a time, and changing the parameters of a rekey requires canceling and starting
+    a new rekey.
+  </dd>
+
+  <dt>Method</dt>
+  <dd>PUT</dd>
+
+  <dt>URL</dt>
+  <dd>`/sys/rekey/init`</dd>
+
+  <dt>Parameters</dt>
+  <dd>
+    <ul>
+      <li>
+        <span class="param">secret_shares</span>
+        <span class="param-flags">required</span>
+        The number of shares to split the master key into.
+      </li>
+      <li>
+        <span class="param">secret_threshold</span>
+        <span class="param-flags">required</span>
+        The number of shares required to reconstruct the master key.
+        This must be less than or equal to <code>secret_shares</code>.
+      </li>
+    </ul>
+  </dd>
+
+  <dt>Returns</dt>
+  <dd>`204` response code.
+  </dd>
+</dl>
+
+## DELETE
+
+<dl>
+  <dt>Description</dt>
+  <dd>
+    Cancels any in-progress rekey. This clears the rekey settings as well as any
+    progress made. This must be called to change the parameters of the rekey.
+  </dd>
+
+  <dt>Method</dt>
+  <dd>DELETE</dd>
+
+  <dt>URL</dt>
+  <dd>`/sys/rekey/init`</dd>
+
+  <dt>Parameters</dt>
+  <dd>None
+  </dd>
+
+  <dt>Returns</dt>
+  <dd>`204` response code.
+  </dd>
+</dl>
+
+# /sys/rekey/update
+
+## PUT
+
+<dl>
+  <dt>Description</dt>
+  <dd>
+    Enter a single master key share to progress the rekey of the Vault.
+    If the threshold number of master key shares is reached, Vault
+    will complete the rekey. Otherwise, this API must be called multiple
+    times until that threshold is met.
+  </dd>
+
+  <dt>Method</dt>
+  <dd>PUT</dd>
+
+  <dt>URL</dt>
+  <dd>`/sys/rekey/update`</dd>
+
+  <dt>Parameters</dt>
+  <dd>
+    <ul>
+      <li>
+        <span class="param">key</span>
+        <span class="param-flags">required</span>
+        A single master share key.
+      </li>
+    </ul>
+  </dd>
+
+  <dt>Returns</dt>
+  <dd>
+    A JSON-encoded object indicating completion and if so with the new master keys:
+
+    ```javascript
+    {
+      "complete": true,
+      "keys": ["one", "two", "three"]
+    }
+    ```
+
+  </dd>
+</dl>
+
diff --git a/website/source/docs/http/sys-remount.html.md b/website/source/docs/http/sys-remount.html.md
new file mode 100644
index 000000000..231e77092
--- /dev/null
+++ b/website/source/docs/http/sys-remount.html.md
@@ -0,0 +1,39 @@
+---
+layout: "http"
+page_title: "HTTP API: /sys/remount"
+sidebar_current: "docs-http-mounts-remount"
+description: |-
+  The '/sys/remount' endpoint is used remount a mounted backend to a new endpoint.
+---
+
+# /sys/remount
+
+<dl>
+  <dt>Description</dt>
+  <dd>
+    Remount an already-mounted backend to a new mount point.
+  </dd>
+
+  <dt>Method</dt>
+  <dd>POST</dd>
+
+  <dt>Parameters</dt>
+  <dd>
+    <ul>
+      <li>
+        <span class="param">from</span>
+        <span class="param-flags">required</span>
+        The previous mount point.
+      </li>
+      <li>
+        <span class="param">to</span>
+        <span class="param-flags">required</span>
+        The new mount point.
+      </li>
+    </ul>
+  </dd>
+
+  <dt>Returns</dt>
+  <dd>`204` response code.
+  </dd>
+</dl>
diff --git a/website/source/docs/http/sys-renew.html.md b/website/source/docs/http/sys-renew.html.md
new file mode 100644
index 000000000..2d806e00f
--- /dev/null
+++ b/website/source/docs/http/sys-renew.html.md
@@ -0,0 +1,38 @@
+---
+layout: "http"
+page_title: "HTTP API: /sys/renew"
+sidebar_current: "docs-http-lease-renew"
+description: |-
+  The `/sys/renew` endpoint is used to renew secrets.
+---
+
+# /sys/renew
+
+<dl>
+  <dt>Description</dt>
+  <dd>
+    Renew a secret, requesting to extend the lease.
+  </dd>
+
+  <dt>Method</dt>
+  <dd>PUT</dd>
+
+  <dt>URL</dt>
+  <dd>`/sys/renew/<lease id>`</dd>
+
+  <dt>Parameters</dt>
+  <dd>
+    <ul>
+      <li>
+        <span class="param">increment</span>
+        <span class="param-flags">optional</span>
+        A requested amount of time in seconds to extend the lease.
+        This is advisory.
+      </li>
+    </ul>
+  </dd>
+
+  <dt>Returns</dt>
+  <dd>A secret structure.
+  </dd>
+</dl>
diff --git a/website/source/docs/http/sys-revoke-prefix.html.md b/website/source/docs/http/sys-revoke-prefix.html.md
new file mode 100644
index 000000000..d400de552
--- /dev/null
+++ b/website/source/docs/http/sys-revoke-prefix.html.md
@@ -0,0 +1,29 @@
+---
+layout: "http"
+page_title: "HTTP API: /sys/revoke-prefix"
+sidebar_current: "docs-http-lease-revoke-prefix"
+description: |-
+  The `/sys/revoke-prefix` endpoint is used to revoke secrets based on prefix.
+---
+
+# /sys/revoke-prefix
+
+<dl>
+  <dt>Description</dt>
+  <dd>
+    Revoke all secrets generated under a given prefix immediately.
+  </dd>
+
+  <dt>Method</dt>
+  <dd>PUT</dd>
+
+  <dt>URL</dt>
+  <dd>`/sys/revoke-prefix/<path prefix>`</dd>
+
+  <dt>Parameters</dt>
+  <dd>None</dd>
+
+  <dt>Returns</dt>
+  <dd>A `204` response code.
+  </dd>
+</dl>
diff --git a/website/source/docs/http/sys-revoke.html.md b/website/source/docs/http/sys-revoke.html.md
new file mode 100644
index 000000000..04672c75d
--- /dev/null
+++ b/website/source/docs/http/sys-revoke.html.md
@@ -0,0 +1,29 @@
+---
+layout: "http"
+page_title: "HTTP API: /sys/revoke"
+sidebar_current: "docs-http-lease-revoke-single"
+description: |-
+  The `/sys/revoke` endpoint is used to revoke secrets.
+---
+
+# /sys/revoke
+
+<dl>
+  <dt>Description</dt>
+  <dd>
+    Revoke a secret immediately.
+  </dd>
+
+  <dt>Method</dt>
+  <dd>PUT</dd>
+
+  <dt>URL</dt>
+  <dd>`/sys/revoke/<lease id>`</dd>
+
+  <dt>Parameters</dt>
+  <dd>None</dd>
+
+  <dt>Returns</dt>
+  <dd>A `204` response code.
+  </dd>
+</dl>
diff --git a/website/source/docs/http/sys-rotate.html.md b/website/source/docs/http/sys-rotate.html.md
new file mode 100644
index 000000000..7b5b07044
--- /dev/null
+++ b/website/source/docs/http/sys-rotate.html.md
@@ -0,0 +1,37 @@
+---
+layout: "http"
+page_title: "HTTP API: /sys/rotate"
+sidebar_current: "docs-http-rotate-rotate"
+description: |-
+  The `/sys/rotate` endpoint is used to rotate the encryption key.
+---
+
+# /sys/rotate
+
+## PUT
+
+<dl>
+  <dt>Description</dt>
+  <dd>
+    Trigger a rotation of the backend encryption key. This is the key that is used
+    to encrypt data written to the storage backend, and is not provided to operators.
+    This operation is done online. Future values are encrypted with the new key, while
+    old values are decrypted with previous encryption keys.
+  </dd>
+
+  <dt>Method</dt>
+  <dd>PUT</dd>
+
+  <dt>URL</dt>
+  <dd>`/sys/rotate`</dd>
+
+  <dt>Parameters</dt>
+  <dd>
+    None
+  </dd>
+
+  <dt>Returns</dt>
+  <dd>`204` response code.
+  </dd>
+</dl>
+
diff --git a/website/source/docs/http/sys-seal-status.html.md b/website/source/docs/http/sys-seal-status.html.md
new file mode 100644
index 000000000..fa996f343
--- /dev/null
+++ b/website/source/docs/http/sys-seal-status.html.md
@@ -0,0 +1,39 @@
+---
+layout: "http"
+page_title: "HTTP API: /sys/seal-status"
+sidebar_current: "docs-http-seal-status"
+description: |-
+  The '/sys/seal-status' endpoint is used to check the seal status of a Vault.
+---
+
+# /sys/seal-status
+
+<dl>
+  <dt>Description</dt>
+  <dd>
+    Returns the seal status of the Vault.
+  </dd>
+
+  <dt>Method</dt>
+  <dd>GET</dd>
+
+  <dt>Parameters</dt>
+  <dd>
+    None
+  </dd>
+
+  <dt>Returns</dt>
+  <dd>
+    The "t" parameter is the threshold, and "n" is the number of shares.
+
+    ```javascript
+    {
+      "sealed": true,
+      "t": 3,
+      "n": 5,
+      "progress": 2
+    }
+    ```
+
+  </dd>
+</dl>
diff --git a/website/source/docs/http/sys-seal.html.md b/website/source/docs/http/sys-seal.html.md
new file mode 100644
index 000000000..8f9765d4c
--- /dev/null
+++ b/website/source/docs/http/sys-seal.html.md
@@ -0,0 +1,28 @@
+---
+layout: "http"
+page_title: "HTTP API: /sys/seal"
+sidebar_current: "docs-http-seal-seal"
+description: |-
+  The '/sys/seal' endpoint seals the Vault.
+---
+
+# /sys/seal
+
+<dl>
+  <dt>Description</dt>
+  <dd>
+    Seals the Vault.
+  </dd>
+
+  <dt>Method</dt>
+  <dd>PUT</dd>
+
+  <dt>Parameters</dt>
+  <dd>
+    None
+  </dd>
+
+  <dt>Returns</dt>
+  <dd>A `204` response code.
+  </dd>
+</dl>
diff --git a/website/source/docs/http/sys-unseal.html.md b/website/source/docs/http/sys-unseal.html.md
new file mode 100644
index 000000000..699db4614
--- /dev/null
+++ b/website/source/docs/http/sys-unseal.html.md
@@ -0,0 +1,36 @@
+---
+layout: "http"
+page_title: "HTTP API: /sys/seal-unseal"
+sidebar_current: "docs-http-seal-unseal"
+description: |-
+  The '/sys/seal-unseal' endpoint is used to unseal the Vault.
+---
+
+# /sys/unseal
+
+<dl>
+  <dt>Description</dt>
+  <dd>
+    Enter a single master key share to progress the unsealing of the Vault.
+    If the threshold number of master key shares is reached, Vault
+    will attempt to unseal the Vault. Otherwise, this API must be
+    called multiple times until that threshold is met.
+  </dd>
+
+  <dt>Method</dt>
+  <dd>PUT</dd>
+
+  <dt>Parameters</dt>
+  <dd>
+    <ul>
+      <li>
+        <span class="param">key</span>
+        <span class="param-flags">required</span>
+        A single master share key.
+      </li>
+    </ul>
+  </dd>
+  <dt>Returns</dt>
+  <dd>The same result as `/sys/seal-status`.
+  </dd>
+</dl>
diff --git a/website/source/docs/index.html.markdown b/website/source/docs/index.html.markdown
new file mode 100644
index 000000000..f62c30f51
--- /dev/null
+++ b/website/source/docs/index.html.markdown
@@ -0,0 +1,14 @@
+---
+layout: "docs"
+page_title: "Documentation"
+sidebar_current: "docs-home"
+description: |-
+  Welcome to the Vault documentation! This documentation is more of a reference guide for all available features and options of Vault. If you're just getting started with Vault, please start with the introduction and getting started guide instead.
+---
+
+# Vault Documentation
+
+Welcome to the Vault documentation! This documentation is more of a reference
+guide for all available features and options of Vault. If you're just getting
+started with Vault, please start with the
+[introduction and getting started guide](/intro/index.html) instead.
diff --git a/website/source/docs/install/index.html.md b/website/source/docs/install/index.html.md
new file mode 100644
index 000000000..3fef65c65
--- /dev/null
+++ b/website/source/docs/install/index.html.md
@@ -0,0 +1,63 @@
+---
+layout: "docs"
+page_title: "Install Vault"
+sidebar_current: "docs-install"
+description: |-
+  Learn how to install Vault.
+---
+
+# Install Vault
+
+Installing Vault is simple. There are two approaches to installing Vault:
+downloading a precompiled binary for your system, or installing from source.
+
+Downloading a precompiled binary is easiest, and we provide downloads over
+TLS along with SHA256 sums to verify the binary is what we say it is. We
+also distribute a PGP signature with the SHA256 sums that can be verified.
+However, we use a 3rd party storage host, and some people feel that
+due to the importance of security with Vault, they'd rather compile it
+from source.
+
+For this reason, we also document on this page how to compile Vault
+from source, from the same versions of all dependent libraries that
+we used for the official builds.
+
+## Precompiled Binaries
+
+To install the precompiled binary,
+[download](/downloads.html) the appropriate package for your system.
+Vault is currently packaged as a zip file. We don't have any near term
+plans to provide system packages.
+
+Once the zip is downloaded, unzip it into any directory. The
+`vault` binary inside is all that is necessary to run Vault (or
+`vault.exe` for Windows). Any additional files, if any, aren't
+required to run Vault.
+
+Copy the binary to anywhere on your system. If you intend to access it
+from the command-line, make sure to place it somewhere on your `PATH`.
+
+## Compiling from Source
+
+To compile from source, you'll need [Go](https://golang.org) installed
+and configured properly. You'll also need Git.
+
+  1. Clone the Vault repository into your GOPATH: https://github.com/hashicorp/vault
+
+  1. Verify that the file `$GOPATH/src/github.com/hashicorp/vault/main.go`
+     exists. If it doesn't, then you didn't clone Vault into the proper
+     path.
+
+  1. Run `make dev`. This will build Vault for your current system
+     and put the binary in `bin` (relative to the git checkout).
+
+~> **Note:** All the dependencies of Vault are vendored and the command
+above will use these vendored binaries. This is to avoid malicious
+upstream dependencies if possible.
+
+## Verifying the Installation
+
+To verify Vault is properly installed, execute the `vault` binary on
+your system. You should see help output. If you are executing it from
+the command line, make sure it is on your PATH or you may get an error
+about `vault` not being found.
diff --git a/website/source/docs/internals/architecture.html.md b/website/source/docs/internals/architecture.html.md
new file mode 100644
index 000000000..c1f2b062e
--- /dev/null
+++ b/website/source/docs/internals/architecture.html.md
@@ -0,0 +1,157 @@
+---
+layout: "docs"
+page_title: "Architecture"
+sidebar_current: "docs-internals-architecture"
+description: |-
+  Learn about the internal architecture of Vault.
+---
+
+# Architecture
+
+Vault is a complex system that has many different pieces. To help both users and developers of Vault
+build a mental model of how it works, this page documents the system architecture.
+
+~> **Advanced Topic!** This page covers technical details
+of Vault. You don't need to understand these details to
+effectively use Vault. The details are documented here for
+those who wish to learn about them without having to go
+spelunking through the source code. However, if you're an
+operator of Vault, we recommend learning about the architecture
+due to the importance of Vault in an environment.
+
+# Glossary
+
+Before describing the architecture, we provide a glossary of terms to help
+clarify what is being discussed:
+
+* **Storage Backend** - A storage backend is responsible for durable storage of _encrypted_ data.
+  Backends are not trusted by Vault and are only expected to provide durability. The storage
+  backend is configured when starting the Vault server.
+
+* **Barrier** - The barrier is cryptographic steel and concrete around the Vault. All data that
+  flows between Vault and the Storage Backend passes through the barrier. The barrier ensures
+  that only encrypted data is written out, and that data is verified and decrypted on the way
+  in. Much like a bank vault, the barrier must be "unsealed" before anything inside can be accessed.
+
+* **Secret Backend** - A secret backend is responsible for managing secrets. Simple secret backends
+  like the "generic" backend simply return the same secret when queried. Some backends support
+  using policies to dynamically generate a secret each time they are queried. This allows for
+  unique secrets to be used which allows Vault to do fine-grained revocation and policy updates.
+  As an example, a MySQL backend could be configured with a "web" policy. When the "web" secret
+  is read, a new MySQL user/password pair will be generated with a limited set of privileges
+  for the web server.
+
+* **Audit Backend** - An audit backend is responsible for managing audit logs. Every request to Vault
+  and response from Vault goes through the configured audit backends. This provides a simple
+  way to integrate Vault with multiple audit logging destinations of different types.
+
+* **Credential Backend** - A credential backend is used to authenticate users or applications which
+  are connecting to Vault. Once authenticated, the backend returns the list of applicable policies
+  which should be applied. Vault takes an authenticated user and returns a client token that can
+  be used for future requests. As an example, the `user-password` backend uses a username and password
+  to authenticate the user. Alternatively, the `github` backend allows users to authenticate
+  via GitHub.
+
+* **Client Token** - A client token is a conceptually similar to a session cookie on a web site.
+  Once a user authenticates, Vault returns a client token which is used for future requests.
+  The token is used by Vault to verify the identity of the client and to enforce the applicable
+  ACL policies.
+
+* **Secret** - A secret is the term for anything returned by Vault which contains confidential
+  or cryptographic material. Not everything returned by Vault is a secret, for example
+  system configuration, status information, or backend policies are not considered Secrets.
+  Secrets always have an associated lease. This means clients cannot assume that the secret
+  contents can be used indefinitely. Vault will revoke a secret at the end of the lease, and
+  an operator may intervene to revoke the secret before the lease is over. This contract
+  between Vault and its clients is critical, as it allows for changes in keys and policies
+  without manual intervention.
+
+* **Server** - Vault depends on a long-running instance which operates as a server.
+  The Vault server provides an API which clients interact with and manages the
+  interaction between all the backends, ACL enforcement, and secret lease revocation.
+  Having a server based architecture decouples clients from the security keys and policies,
+  enables centralized audit logging and simplifies administration for operators.
+
+# High-Level Overview
+
+A very high level overview of Vault looks like this:
+
+![Architecture Overview](/assets/images/layers.png)
+
+Let's begin to break down this picture. There is a clear separation of components
+that are inside or outside of the security barrier. Only the storage backend and
+the HTTP API are outside, all other components are inside the barrier.
+
+The storage backend is untrusted and is used to durably store encrypted data. When
+the Vault server is started, it must be provided with a storage backend so that data
+is available across restarts. The HTTP API similarly must be started by the Vault server
+on start so that clients can interact with it.
+
+Once started, the Vault is in a _sealed_ state. Before any operation can be performed
+on the Vault it must be unsealed. This is done by providing the unseal keys. When
+the Vault is initialized it generates an encryption key which is used to protect all the
+data. That key is protected by a master key. By default, Vault uses a technique known
+as [Shamir's secret sharing algorithm](http://en.wikipedia.org/wiki/Shamir's_Secret_Sharing)
+to split the master key into 5 shares, any 3 of which are required to reconstruct the master
+key.
+
+![Keys](/assets/images/keys.png)
+
+The number of shares and the minimum threshold required can both be specified. Shamir's
+technique can be disabled, and the master key used directly for unsealing. Once Vault
+retrieves the encryption key, it is able to decrypt the data in the storage backend,
+and enters the _unsealed_ state. Once unsealed, Vault loads all of the configured
+audit, credential and secret backends.
+
+The configuration of those backends must be stored in Vault since they are security
+sensitive. Only users with the correct permissions should be able to modify them,
+meaning they cannot be specified outside of the barrier. By storing them in Vault,
+any changes to them are protected by the ACL system and tracked by audit logs.
+
+After the Vault is unsealed, requests can be processed from the HTTP API to the Core.
+The core is used to manage the flow of requests through the system, enforce ACLs,
+and ensure audit logging is done.
+
+When a client first connects to Vault, it needs to authenticate. Vault provides
+configurable credential backends providing flexibility in the authentication mechanism
+used. Human friendly mechanisms such as username/password or GitHub might be
+used for operators, while applications may use public/private keys or tokens to authenticate.
+An authentication request flows through core and into a credential backend, which determines
+if the request is valid and returns a list of associated policies.
+
+Policies are just a named ACL rule. For example, the "root" policy is builtin and
+permits access to all resources. You can create any number of named policies with
+fine-grained control over paths. Vault operates exclusively in a blacklist mode, meaning
+unless access is explicitly granted via a policy the action is not allowed.
+Since a user may have multiple policies associated, an action is allowed if any policy
+permits it. Policies are stored and managed by an internal policy store. This internal store
+is manipulated through the system backend, which is always mounted at `sys/`.
+
+Once authentication takes place and a credential backend provides a set of applicable
+policies, a new client token is generated and managed by the token store. This client token
+is sent back to the client, and is used to make future requests. This is similar to
+a cookie sent by a website after a user logs in. The client token may have a lease associated
+with it depending on the credential backend configuration. This means the client token
+may need to be periodically renewed to avoid invalidation.
+
+Once authenticated, requests are made providing the client token. The token is used
+to verify the client is authorized and to load the relevant policies. The policies
+are used to authorize the client request. The request is then routed to the secret backend,
+which is processed depending on the type of backend. If the backend returns a secret,
+the core registers it with the expiration manager and attaches a lease ID.
+The lease ID is used by clients to renew or revoke their secret. If a client allows the
+lease to expire, the expiration manager automatically revokes the secret.
+
+The core handles logging of requests and responses to the audit broker, which fans the
+request out to all the configured audit backends. Outside of the request flow, the core
+performs certain background activity. Lease management is critical, as it allows
+expired client tokens or secrets to be revoked automatically. Additionally, Vault handles
+certain partial failure cases by using write ahead logging with a rollback manager.
+This is managed transparently within the core and is not user visible.
+
+# Getting in Depth
+
+This has been a brief high-level overview of the architecture of Vault. There
+are more details available for each of the sub-systems.
+
+For other details, either consult the code, ask in IRC or reach out to the mailing list.
diff --git a/website/source/docs/internals/high-availability.html.md b/website/source/docs/internals/high-availability.html.md
new file mode 100644
index 000000000..270401e6f
--- /dev/null
+++ b/website/source/docs/internals/high-availability.html.md
@@ -0,0 +1,49 @@
+---
+layout: "docs"
+page_title: "High Availability"
+sidebar_current: "docs-internals-ha"
+description: |-
+  Learn about the high availability design of Vault.
+---
+
+# High Availability
+
+Vault is primarily used in production environments to manage secrets.
+As a result, any downtime of the Vault service can affect downstream clients.
+Vault is designed to support a highly available deploy to ensure a machine
+or process failure is minimally disruptive.
+
+~> **Advanced Topic!** This page covers technical details
+of Vault. You don't need to understand these details to
+effectively use Vault. The details are documented here for
+those who wish to learn about them without having to go
+spelunking through the source code. However, if you're an
+operator of Vault, we recommend learning about the architecture
+due to the importance of Vault in an environment.
+
+# Design Overview
+
+The primary design goal in making Vault highly availability (HA) was to
+minimize downtime and not horizontal scalability. Vault is typically
+bound by the IO limits of the storage backend rather than the compute
+requirements. This simplifies the HA approach and allows more complex
+coordination to be avoided.
+
+Certain storage backends, such as Consul, provide additional coordination
+functions that enable Vault to run in an HA configuration. When supported
+by the backend, Vault will automatically run in HA mode without additional
+configuration.
+
+When running in HA mode, Vault servers have two additional states they
+can be in: standby and active. For multiple Vault servers sharing a storage
+backend, only a single instance will be active at any time while all other
+instances are hot standbys.
+
+The active server operates in a standard fashion and processes all requests.
+The standby servers do not process requests, and instead redirect to the active
+Vault. Meanwhile, if the active server is sealed, fails, or loses network connectivity
+then one of the standbys will take over and become the active instance.
+
+It is important to note that only _unsealed_ servers act as a standby.
+If a server is still in the sealed state, then it cannot act as a standby
+as it would be unable to serve any requests should the active server fail.
diff --git a/website/source/docs/internals/index.html.md b/website/source/docs/internals/index.html.md
new file mode 100644
index 000000000..f2defdf66
--- /dev/null
+++ b/website/source/docs/internals/index.html.md
@@ -0,0 +1,17 @@
+---
+layout: "docs"
+page_title: "Internals"
+sidebar_current: "docs-internals"
+description: |-
+  This section covers the internals of Vault and explains technical details of Vaults operation.
+---
+
+# Vault Internals
+
+This section covers the internals of Vault and explains the technical
+details of how Vault functions, its architecture and security properties.
+
+-> **Note:** Knowledge of Vault internals is not
+required to use Vault. If you aren't interested in the internals
+of Vault, you may safely skip this section. If you're operating Vault,
+we recommend understanding the internals.
diff --git a/website/source/docs/internals/rotation.html.md b/website/source/docs/internals/rotation.html.md
new file mode 100644
index 000000000..fc74d4503
--- /dev/null
+++ b/website/source/docs/internals/rotation.html.md
@@ -0,0 +1,58 @@
+---
+layout: "docs"
+page_title: "Key Rotation"
+sidebar_current: "docs-internals-rotation"
+description: |-
+  Learn about the details of key rotation within Vault.
+---
+
+# Key Rotation
+
+Vault has multiple encryption keys that are used for various purposes. These keys support
+rotation so that they can be periodically changed or in response to a potential leak or
+compromise. It is useful to first understand the
+[high-level architecture](/docs/internals/architecture.html) before learning about key rotation.
+
+As a review, Vault starts in a _sealed_ state. Vault is unsealed by providing the unseal keys.
+By default, Vault uses a technique known as [Shamir's secret sharing algorithm](http://en.wikipedia.org/wiki/Shamir's_Secret_Sharing)
+to split the master key into 5 shares, any 3 of which are required to reconstruct the master
+key. The master key is used to protect the encryption key, which is ultimately used to protect
+data written to the storage backend.
+
+![Keys](/assets/images/keys.png)
+
+To support key rotation, we need to support changing the unseal keys, master key, and the
+backend encryption key. We split this into two seperate operations, `rekey` and `rotate`.
+
+The `rekey` operation is used to generate a new master key. When this is being done,
+it is possible to change the parameters of the key splitting, so that the number of shares
+and the threshold required to unseal can be changed. To perform a rekey a threshold of the
+current unseal keys must be provided. This is to prevent a single malicious operator from
+performing a rekey and invaliding the existing master key.
+
+Performing a rekey is fairly straightforward. The rekey operation must be initialized with
+the new parameters for the split and threshold. Once initialized, the current unseal keys
+must be provided until the threshold is met. Once met, Vault will generate the new master
+key, perform the splitting, and re-encrypt the encryption key with the new master key.
+The new unseal keys are then provided to the operator, and the old unseal keys are no
+longer usable.
+
+The `rotate` operation is used to change the encryption key used to protect data written
+to the storage backend. This key is never provided or visible to operators, who only
+have unseal keys. This simplifies the rotation, as it does not require the current key
+holders unlike the `rekey` operation. When `rotate` is triggered, a new encryption key
+is generated and added to a keyring. All new values written to the storage backend are
+encrypted with the new key. Old values written with previous encryption keys can still
+be decrypted since older keys are saved in the keyring. This allows key rotation to be
+done online, without an expensive re-encryption process.
+
+Both the `rekey` and `rotate` operations can be done online and in a highly available
+configuration. Only the active Vault instance can perform either of the operations
+but standby instances can still assume an active role after either operation. This is
+done by providing an online upgrade path for standby instances. If the current encryption
+key is `N` and a rotation installs `N+1`, Vault creates a special "upgrade" key, which
+provides the `N+1` encryption key protected by the `N` key. This upgrade key is only available
+for a few minutes enabling standby instances do a periodic check for upgrades.
+This allows standby instances to update their keys and stay in-sync with the active Vault
+without requiring operators to perform another unseal.
+
diff --git a/website/source/docs/internals/security.html.md b/website/source/docs/internals/security.html.md
new file mode 100644
index 000000000..6ebbf628e
--- /dev/null
+++ b/website/source/docs/internals/security.html.md
@@ -0,0 +1,148 @@
+---
+layout: "docs"
+page_title: "Security Model"
+sidebar_current: "docs-internals-security"
+description: |-
+  Learn about the security model of Vault.
+---
+
+# Security Model
+
+Due to the nature of Vault and the confidentiality of data it is managing,
+the Vault security model is very critical. The overall goal of Vault's security
+model is to provide [confidentiality, integrity, availability, accountability,
+authentication](http://en.wikipedia.org/wiki/Information_security).
+
+This means that data at rest and in transit must be secure from eavesdropping
+or tampering. Clients must be appropriately authenticated and authorized
+to access data or modify policy. All interactions must be auditable and traced
+uniquely back to the origin entity. The system must be robust against intentional
+attempts to bypass any of its access controls.
+
+# Threat Model
+
+The following are the various parts of the Vault threat model:
+
+* Eavesdropping on any Vault communication. Client communication with Vault
+  should be secure from eavesdropping as well as communication from Vault to
+  its storage backend.
+
+* Tampering with data at rest or in transit. Any tampering should be detectable
+  and cause Vault to abort processing of the transaction.
+
+* Access to data or controls without authentication or authorization. All requests
+  must be proceeded by the applicable security policies.
+
+* Access to data or controls without accountability. If audit logging
+  is enabled, requests and responses must be logged before the client receives
+  any secret material.
+
+* Confidentiality of stored secrets. Any data that leaves Vault to rest in the
+  storage backend must be safe from eavesdropping. In practice, this means all
+  data at rest must be encrypted.
+
+* Availability of secret material in the face of failure. Vault supports
+  running in a highly available configuration to avoid loss of availability.
+
+The following are not parts of the Vault threat model:
+
+* Protecting against arbitrary control of the storage backend. An attacker
+  that can perform arbitrary operations against the storage backend can
+  undermine security in any number of ways that are difficult or impossible to protect
+  against. As an example, an attacker could delete or corrupt all the contents
+  of the storage backend causing total data loss for Vault. The ability to control
+  reads would allow an attacker to snapshot in a well-known state and rollback state
+  changes if that would be beneficial to them.
+
+* Protecting against the leakage of the existence of secret material. An attacker
+  that can read from the storage backend may observe that secret material exists
+  and is stored, even if it is kept confidential.
+
+* Protecting against memory analysis of a running Vault. If an attacker is able
+  to inspect the memory state of a running Vault instance then the confidentiality
+  of data may be compromised.
+
+# External Threat Overview
+
+Given the architecture of Vault, there are 3 distinct systems we are concerned with
+for Vault. There is the client, which is speaking to Vault over an API. There is Vault
+or the server more accurately, which is providing an API and serving requests. Lastly,
+there is the storage backend, which the server is utilizing to read and write data.
+
+There is no mutual trust between the Vault client and server. Clients use
+[TLS](http://en.wikipedia.org/wiki/Transport_Layer_Security) to verify the identity
+of the server and to establish a secure communication channel. Servers require that
+a client provides a client token for every request which is used to identify the client.
+A client that does not provide their token is only permitted to make login requests.
+
+The storage backends used by Vault are also untrusted by design. Vault uses a security
+barrier for all requests made to the backend. The security barrier automatically encrypts
+all data leaving Vault using the [Advanced Encryption Standard (AES)](http://en.wikipedia.org/wiki/Advanced_Encryption_Standard)
+cipher in the [Galois Counter Mode (GCM)](http://en.wikipedia.org/wiki/Galois/Counter_Mode).
+The nonce is randomly generated for every encrypted object. When data is read from the
+security barrier the GCM authentication tag is verified prior to decryption to detect
+any tampering.
+
+Depending on the backend used, Vault may communicate with the backend over TLS
+to provide an added layer of security. In some cases, such as a file backend this
+is not applicable. Because storage backends are untrusted, an eavesdropper would
+only gain access to encrypted data even if communication with the backend was intercepted.
+
+# Internal Threat Overview
+
+Within the Vault system, a critical security concern is an attacker attempting
+to gain access to secret material they are not authorized to. This is an internal
+threat if the attacker is already permitted some level of access to Vault and is
+able to authenticate.
+
+When a client first authenticates with Vault, a credential backend is used to
+verify the identity of the client and to return a list of associated ACL policies.
+This association is configured by operators of Vault ahead of time. For example,
+GitHub users in the "engineering" team may be mapped to the "engineering" and "ops"
+Vault policies. Vault then generates a client token which is a randomly generated
+UUID and maps it to the policy list. This client token is then returned to the client.
+
+On each request a client provides this token. Vault then uses it to check that the token
+is valid and has not been revoked or expired, and generates an ACL based on the associated
+policies. Vault uses a strict default deny or whitelist enforcement. This means unless
+an associated policy allows for a given action, it will be denied. Each policy specifies
+a level of access granted to a path in Vault. When the policies are merged (if multiple
+policies are associated with a client), the highest access level permitted is used.
+For example, if the "engineering" policy permits read/write access to the "eng/" path,
+and the "ops" policy permits read access to the "ops/" path, then the user gets the
+union of those. Policy is matched using the most specific defined policy, which may be
+an exact match or the longest-prefix match glob pattern.
+
+Certain operations are only permitted by "root" users, which is a distinguished
+policy built into Vault. This is similar to the concept of a root user on a Unix system
+or an Administrator on Windows. Although clients could be provided with root tokens
+or associated with the root policy, instead Vault supports the notion of "sudo" privilege.
+As part of a policy, users may be granted "sudo" privileges to certain paths, so that
+they can still perform security sensitive operations without being granted global
+root access to Vault.
+
+Lastly, Vault supports using a [Two-man rule](http://en.wikipedia.org/wiki/Two-man_rule) for
+unsealing using [Shamir's Secret Sharing technique](http://en.wikipedia.org/wiki/Shamir's_Secret_Sharing).
+When Vault is started, it starts in an _sealed_ state. This means that the encryption key
+needed to read and write from the storage backend is not yet known. The process of unsealing
+requires providing the master key so that the encryption key can be retrieved. The risk of distributing
+the master key is that a single malicious actor with access to it can decrypt the entire
+Vault. Instead, Shamir's technique allows us to split the master key into multiple shares or parts.
+The number of shares and the threshold needed is configurable, but by default Vault generates
+5 shares, any 3 of which must be provided to reconstruct the master key.
+
+By using a secret sharing technique, we avoid the need to place absolute trust in the holder
+of the master key, and avoid storing the master key at all. The master key is only
+retrievable by reconstructing the shares. The shares are not useful for making any requests
+to Vault, and can only be used for unsealing. Once unsealed the standard ACL mechanisms
+are used for all requests.
+
+To make an analogy, a bank puts security deposit boxes inside of a vault.
+Each security deposit box has a key, while the vault door has both a combination and a key.
+The vault is encased in steel and concrete so that the door is the only practical entrance.
+The analogy to Vault, is that the cryptosystem is the steel and concrete protecting the data.
+While you could tunnel through the concrete or brute force the encryption keys, it would be
+prohibitively time consuming. Opening the bank vault requires two-factors: the key and the combination.
+Similarly, Vault requires multiple shares be provided to reconstruct the master key.
+Once unsealed, each security deposit boxes still requires the owner provide a key, and similarly
+the Vault ACL system protects all the secrets stored.
diff --git a/website/source/docs/internals/telemetry.html.md b/website/source/docs/internals/telemetry.html.md
new file mode 100644
index 000000000..86baa878b
--- /dev/null
+++ b/website/source/docs/internals/telemetry.html.md
@@ -0,0 +1,48 @@
+---
+layout: "docs"
+page_title: "Telemetry"
+sidebar_current: "docs-internals-telemetry"
+description: |-
+  Learn about the telemetry data available in Vault.
+---
+
+# Telemetry
+
+The Vault agent collects various runtime metrics about the performance of
+different libraries and subsystems. These metrics are aggregated on a ten
+second interval and are retained for one minute.
+
+To view this data, you must send a signal to the Vault process: on Unix,
+this is `USR1` while on Windows it is `BREAK`. Once Vault receives the signal,
+it will dump the current telemetry information to the agent's `stderr`.
+
+This telemetry information can be used for debugging or otherwise
+getting a better view of what Vault is doing.
+
+Telemetry information can be streamed to both [statsite](http://github.com/armon/statsite)
+as well as statsd based on providing the appropriate configuration options.
+
+Below is sample output of a telemetry dump:
+
+```text
+[2015-04-20 12:24:30 -0700 PDT][G] 'vault.runtime.num_goroutines': 12.000
+[2015-04-20 12:24:30 -0700 PDT][G] 'vault.runtime.free_count': 11882.000
+[2015-04-20 12:24:30 -0700 PDT][G] 'vault.runtime.total_gc_runs': 9.000
+[2015-04-20 12:24:30 -0700 PDT][G] 'vault.expire.num_leases': 1.000
+[2015-04-20 12:24:30 -0700 PDT][G] 'vault.runtime.alloc_bytes': 502992.000
+[2015-04-20 12:24:30 -0700 PDT][G] 'vault.runtime.sys_bytes': 3999992.000
+[2015-04-20 12:24:30 -0700 PDT][G] 'vault.runtime.malloc_count': 17315.000
+[2015-04-20 12:24:30 -0700 PDT][G] 'vault.runtime.heap_objects': 5433.000
+[2015-04-20 12:24:30 -0700 PDT][G] 'vault.runtime.total_gc_pause_ns': 3794124.000
+[2015-04-20 12:24:30 -0700 PDT][S] 'vault.audit.log_response': Count: 2 Min: 0.001 Mean: 0.001 Max: 0.001 Stddev: 0.000 Sum: 0.002
+[2015-04-20 12:24:30 -0700 PDT][S] 'vault.route.read.secret-': Count: 1 Sum: 0.036
+[2015-04-20 12:24:30 -0700 PDT][S] 'vault.barrier.get': Count: 3 Min: 0.004 Mean: 0.021 Max: 0.050 Stddev: 0.025 Sum: 0.064
+[2015-04-20 12:24:30 -0700 PDT][S] 'vault.token.lookup': Count: 2 Min: 0.040 Mean: 0.074 Max: 0.108 Stddev: 0.048 Sum: 0.148
+[2015-04-20 12:24:30 -0700 PDT][S] 'vault.policy.get_policy': Count: 2 Min: 0.003 Mean: 0.004 Max: 0.005 Stddev: 0.001 Sum: 0.009
+[2015-04-20 12:24:30 -0700 PDT][S] 'vault.core.check_token': Count: 2 Min: 0.053 Mean: 0.087 Max: 0.121 Stddev: 0.048 Sum: 0.174
+[2015-04-20 12:24:30 -0700 PDT][S] 'vault.audit.log_request': Count: 2 Min: 0.001 Mean: 0.001 Max: 0.001 Stddev: 0.000 Sum: 0.002
+[2015-04-20 12:24:30 -0700 PDT][S] 'vault.barrier.put': Count: 3 Min: 0.004 Mean: 0.010 Max: 0.019 Stddev: 0.008 Sum: 0.029
+[2015-04-20 12:24:30 -0700 PDT][S] 'vault.route.write.secret-': Count: 1 Sum: 0.035
+[2015-04-20 12:24:30 -0700 PDT][S] 'vault.core.handle_request': Count: 2 Min: 0.097 Mean: 0.228 Max: 0.359 Stddev: 0.186 Sum: 0.457
+[2015-04-20 12:24:30 -0700 PDT][S] 'vault.expire.register': Count: 1 Sum: 0.18
+```
diff --git a/website/source/docs/internals/token.html.md b/website/source/docs/internals/token.html.md
new file mode 100644
index 000000000..d13c3ccfe
--- /dev/null
+++ b/website/source/docs/internals/token.html.md
@@ -0,0 +1,53 @@
+---
+layout: "docs"
+page_title: "Token Authentication"
+sidebar_current: "docs-internals-token"
+description: |-
+  Learn about the client token authentication in Vault.
+---
+
+# Token Authentication
+
+The `token` authentication backend is built-in and is at the core of
+client authentication. Other authentication backends may be used to
+authenticate a client, but they eventually result in the generation of a client
+token managed by the `token` backend.
+
+Every token has a number of properties:
+
+* ID - The primary ID of a token is a randomly generated UUID
+* Display Name - Optionally, a human readable display name
+* Metadata - Metadata used for audit logging
+* Number of Uses - Optionally, a restricted use count
+* Parent ID - Optionally, a parent token which created this child token
+* Policies - An associated list of ACL policies
+* Source Path - The path at which the token was generated (e.g. `auth/github/login`)
+
+The properties of a token are immutable once created. The exception to this
+is the number of uses, which is decremented on each request. Each of these
+properties enable Vault to do a number of interesting things.
+
+Each token maintains the source path, or the login path, that was used
+to create the token. This is used to allow source based revocation. For example,
+if we believe our GitHub organization was compromised, we may want to revoke
+all tokens generated via `auth/github/login`. This would be done by using the
+`auth/token/revoke-prefix/` API with the `auth/github/` prefix. Revoking the
+prefix will revoke all client tokens generated at that path, as well as all
+dynamic secrets generated by those tokens. This provides a powerful "break glass"
+procedure during a potential compromise.
+
+If a token is created by another authentication backend, they do not have
+a parent token. However, any tokens created by the `auth/token/create` API
+have a parent token, namely the token used to make that request. By maintaining
+this parent-child relationship, Vault models token trees. Child tokens can
+be created with a subset of the parent policies, allowing for dropping of
+privileges. When a token is revoked, the entire sub-tree of tokens is revoked
+with it. This allows clients to safely generate child tokens and then revoke
+them all along with the root.
+
+Child tokens are very useful, especially when combined with limited use tokens.
+When a token is created, its use count can be optionally specified. Providing
+a use count of one makes a _one time token_. This means the token can be used
+for a single request before being automatically revoked. This can be generalized
+to any number of uses. Limited use tokens cannot be used to create sub-tokens,
+but they can be a powerful way to allow extremely limited access to Vault.
diff --git a/website/source/docs/secrets/aws/index.html.md b/website/source/docs/secrets/aws/index.html.md
new file mode 100644
index 000000000..17feb3306
--- /dev/null
+++ b/website/source/docs/secrets/aws/index.html.md
@@ -0,0 +1,358 @@
+---
+layout: "docs"
+page_title: "Secret Backend: AWS"
+sidebar_current: "docs-secrets-aws"
+description: |-
+  The AWS secret backend for Vault generates access keys dynamically based on IAM policies.
+---
+
+# AWS Secret Backend
+
+Name: `aws`
+
+The AWS secret backend for Vault generates AWS access credentials dynamically
+based on IAM policies. This makes IAM much easier to use: credentials could
+be generated on the fly, and are automatically revoked when the Vault
+lease is expired.
+
+This page will show a quick start for this backend. For detailed documentation
+on every path, use `vault path-help` after mounting the backend.
+
+## Quick Start
+
+The first step to using the aws backend is to mount it.
+Unlike the `generic` backend, the `aws` backend is not mounted by default.
+
+```text
+$ vault mount aws
+Successfully mounted 'aws' at 'aws'!
+```
+
+Next, we must configure the root credentials that are used to manage IAM credentials:
+
+```text
+$ vault write aws/config/root \
+    access_key=AKIAJWVN5Z4FOFT7NLNA \
+    secret_key=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 \
+    region=us-east-1
+```
+
+The following parameters are required:
+
+- `access_key` - the AWS access key that has permission to manage IAM
+  credentials.
+- `secret_key` - the AWS secret key that has permission to manage IAM
+  credentials.
+- `region` the AWS region for API calls.
+
+The next step is to configure a role. A role is a logical name that maps
+to a policy used to generated those credentials. For example, lets create
+a "deploy" role:
+
+```text
+$ vault write aws/roles/deploy \
+    name=deploy \
+    policy=@policy.json
+```
+
+This path will create a named role along with the IAM policy used
+to restrict permissions for it. This is used to dynamically create
+a new pair of IAM credentials when needed.
+
+The `@` tells Vault to load the policy from the file named `policy.json`. Here
+is an example IAM policy to get started:
+
+```javascript
+{
+  "Version": "2012-10-17",
+  "Statement": {
+    "Effect": "Allow",
+    "Action": "iam:*",
+    "Resource": "*"
+  }
+}
+```
+
+For more information on IAM policies, please see the
+[AWS IAM policy documentation](http://docs.aws.amazon.com/IAM/latest/UserGuide/PoliciesOverview.html).
+
+To generate a new set of IAM credentials, we simply read from that role:
+
+```text
+$ vault read aws/creds/deploy
+Key             Value
+lease_id        aws/creds/deploy/7cb8df71-782f-3de1-79dd-251778e49f58
+lease_duration  3600
+access_key      AKIAIOMYUTSLGJOGLHTQ
+secret_key      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
+```
+
+If you run the command again, you will get a new set of credentials:
+
+```text
+$ vault read aws/creds/deploy
+Key             Value
+lease_id        aws/creds/deploy/82d89562-ff19-382e-6be9-cb45c8f6a42d
+lease_duration  3600
+access_key      AKIAJZ5YRPHFH3QHRRRQ
+secret_key      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
+```
+
+If you get an error message similar to either of the following, the root credentials that you wrote to `aws/config/root` have insufficient privilege:
+
+```text
+$ vault read aws/creds/deploy
+* Error creating IAM user: User: arn:aws:iam::000000000000:user/hashicorp is not authorized to perform: iam:CreateUser on resource: arn:aws:iam::000000000000:user/vault-root-1432735386-4059
+
+$ vault revoke aws/creds/deploy/774cfb27-c22d-6e78-0077-254879d1af3c
+Revoke error: Error making API request.
+
+URL: PUT http://127.0.0.1:8200/v1/sys/revoke/aws/creds/deploy/774cfb27-c22d-6e78-0077-254879d1af3c
+Code: 400. Errors:
+
+* invalid request
+```
+
+The root credentials need permission to perform various IAM actions. These are the actions that the AWS secret backend uses to manage IAM credentials. Here is an example IAM policy that would grant these permissions:
+
+```javascript
+{
+    "Version": "2012-10-17",
+    "Statement": [
+        {
+            "Effect": "Allow",
+            "Action": [
+                "iam:CreateAccessKey",
+                "iam:CreateUser",
+                "iam:PutUserPolicy",
+                "iam:ListGroupsForUser",
+                "iam:ListUserPolicies",
+                "iam:ListAccessKeys",
+                "iam:DeleteAccessKey",
+                "iam:DeleteUserPolicy",
+                "iam:RemoveUserFromGroup",
+                "iam:DeleteUser"
+            ],
+            "Resource": [
+                "arn:aws:iam::ACCOUNT-ID-WITHOUT-HYPHENS:user/vault-*"
+            ]
+        }
+    ]
+}
+```
+
+Note that this policy example is unrelated to the policy you wrote to `aws/roles/deploy`. This policy example should be applied to the IAM user (or role) associated with the root credentials that you wrote to `aws/config/root`. You have to apply it yourself in IAM. The policy you wrote to `aws/roles/deploy` is the policy you want the AWS secret backend to apply to the temporary credentials it returns from `aws/creds/deploy`.
+
+If you get stuck at any time, simply run `vault path-help aws` or with a subpath for
+interactive help output.
+
+## API
+
+### /aws/config/root
+#### POST
+
+<dl class="api">
+  <dt>Description</dt>
+  <dd>
+    Configures the root IAM credentials used.
+    This is a root protected endpoint.
+  </dd>
+
+  <dt>Method</dt>
+  <dd>POST</dd>
+
+  <dt>URL</dt>
+  <dd>`/aws/config/root`</dd>
+
+  <dt>Parameters</dt>
+  <dd>
+    <ul>
+      <li>
+        <span class="param">access_key</span>
+        <span class="param-flags">required</span>
+        The AWS Access Key
+      </li>
+      <li>
+        <span class="param">secret_key</span>
+        <span class="param-flags">required</span>
+        The AWS Secret Key
+      </li>
+      <li>
+        <span class="param">region</span>
+        <span class="param-flags">required</span>
+        The AWS region for API calls
+      </li>
+    </ul>
+  </dd>
+
+  <dt>Returns</dt>
+  <dd>
+    A `204` response code.
+  </dd>
+</dl>
+
+### /aws/config/lease
+#### POST
+
+<dl class="api">
+  <dt>Description</dt>
+  <dd>
+    Configures the lease settings for generated credentials.
+    This is a root protected endpoint.
+  </dd>
+
+  <dt>Method</dt>
+  <dd>POST</dd>
+
+  <dt>URL</dt>
+  <dd>`/aws/config/lease`</dd>
+
+  <dt>Parameters</dt>
+  <dd>
+    <ul>
+      <li>
+        <span class="param">lease</span>
+        <span class="param-flags">required</span>
+        The lease value provided as a string duration
+        with time suffix. Hour is the largest suffix.
+      </li>
+      <li>
+        <span class="param">lease_max</span>
+        <span class="param-flags">required</span>
+        The maximum lease value provided as a string duration
+        with time suffix. Hour is the largest suffix.
+      </li>
+    </ul>
+  </dd>
+
+  <dt>Returns</dt>
+  <dd>
+    A `204` response code.
+  </dd>
+</dl>
+
+### /aws/roles/
+#### POST
+
+<dl class="api">
+  <dt>Description</dt>
+  <dd>
+    Creates or updates a named role.
+  </dd>
+
+  <dt>Method</dt>
+  <dd>POST</dd>
+
+  <dt>URL</dt>
+  <dd>`/aws/roles/<name>`</dd>
+
+  <dt>Parameters</dt>
+  <dd>
+    <ul>
+      <li>
+        <span class="param">policy</span>
+        <span class="param-flags">required</span>
+        The IAM policy in JSON format.
+      </li>
+    </ul>
+  </dd>
+
+  <dt>Returns</dt>
+  <dd>
+    A `204` response code.
+  </dd>
+</dl>
+
+#### GET
+
+<dl class="api">
+  <dt>Description</dt>
+  <dd>
+    Queries a named role.
+  </dd>
+
+  <dt>Method</dt>
+  <dd>GET</dd>
+
+  <dt>URL</dt>
+  <dd>`/aws/roles/<name>`</dd>
+
+  <dt>Parameters</dt>
+  <dd>
+    None
+  </dd>
+
+  <dt>Returns</dt>
+  <dd>
+
+    ```javascript
+    {
+        "data": {
+            "policy": "..."
+        }
+    }
+    ```
+
+  </dd>
+</dl>
+
+#### DELETE
+
+<dl class="api">
+  <dt>Description</dt>
+  <dd>
+    Deletes a named role.
+  </dd>
+
+  <dt>Method</dt>
+  <dd>DELETE</dd>
+
+  <dt>URL</dt>
+  <dd>`/aws/roles/<name>`</dd>
+
+  <dt>Parameters</dt>
+  <dd>
+    None
+  </dd>
+
+  <dt>Returns</dt>
+  <dd>
+    A `204` response code.
+  </dd>
+</dl>
+
+
+### /aws/creds/
+#### GET
+
+<dl class="api">
+  <dt>Description</dt>
+  <dd>
+    Generates a dynamic IAM credential based on the named role.
+  </dd>
+
+  <dt>Method</dt>
+  <dd>GET</dd>
+
+  <dt>URL</dt>
+  <dd>`/aws/creds/<name>`</dd>
+
+  <dt>Parameters</dt>
+  <dd>
+    None
+  </dd>
+
+  <dt>Returns</dt>
+  <dd>
+
+    ```javascript
+    {
+        "data": {
+            "access_key": "...",
+            "secret_key": "..."
+        }
+    }
+    ```
+
+  </dd>
+</dl>
diff --git a/website/source/docs/secrets/cassandra/index.html.md b/website/source/docs/secrets/cassandra/index.html.md
new file mode 100644
index 000000000..8b8041a16
--- /dev/null
+++ b/website/source/docs/secrets/cassandra/index.html.md
@@ -0,0 +1,332 @@
+---
+layout: "docs"
+page_title: "Secret Backend: Cassandra"
+sidebar_current: "docs-secrets-cassandra"
+description: |-
+  The Cassandra secret backend for Vault generates database credentials to access Cassandra.
+---
+
+# Cassandra Secret Backend
+
+Name: `cassandra`
+
+The Cassandra secret backend for Vault generates database credentials
+dynamically based on configured roles. This means that services that need
+to access a database no longer need to hardcode credentials: they can request
+them from Vault, and use Vault's leasing mechanism to more easily roll keys.
+
+Additionally, it introduces a new ability: with every service accessing
+the database with unique credentials, it makes auditing much easier when
+questionable data access is discovered: you can track it down to the specific
+instance of a service based on the Cassandra username.
+
+This page will show a quick start for this backend. For detailed documentation
+on every path, use `vault path-help` after mounting the backend.
+
+## Quick Start
+
+The first step to using the Cassandra backend is to mount it.
+Unlike the `generic` backend, the `cassandra` backend is not mounted by default.
+
+```text
+$ vault mount cassandra
+Successfully mounted 'cassandra' at 'cassandra'!
+```
+
+Next, Vault must be configured to connect to Cassandra. This is done by
+writing one or more hosts, a username, and a password:
+
+```text
+$ vault write cassandra/config/connection \
+    hosts=localhost username=cassandra password=cassandra
+```
+
+In this case, we've configured Vault with the user "cassandra" and password "cassandra",
+It is important that the Vault user is a superuser, in order to manage other user accounts.
+
+The next step is to configure a role. A role is a logical name that maps
+to a policy used to generated those credentials. For example, lets create
+a "readonly" role:
+
+```text
+$ vault write cassandra/roles/readonly \
+    creation_cql="CREATE USER '{{username}}' WITH PASSWORD '{{password}}' NOSUPERUSER; \
+    GRANT SELECT ON ALL KEYSPACES TO {{username}};"
+Success! Data written to: cassandra/roles/readonly
+```
+
+By writing to the `roles/readonly` path we are defining the `readonly` role.
+This role will be created by evaluating the given `creation_cql` statements. By
+default, the `{{username}}` and `{{password}}` fields will be populated by
+Vault with dynamically generated values. This CQL statement is creating
+the named user, and then granting it `SELECT` or read-only privileges
+to keyspaces. More complex `GRANT` queries can be used to
+customize the privileges of the role. See the [CQL Reference Manual](http://docs.datastax.com/en/cql/3.1/cql/cql_reference/grant_r.html)
+for more information.
+
+To generate a new set of credentials, we simply read from that role:
+Vault is now configured to create and manage credentials for Cassandra!
+
+```text
+$ vault read cassandra/creds/readonly
+Key           	Value
+lease_id       	cassandra/creds/test/7a23e890-3a26-531d-529b-92d18d1fa63f
+lease_duration 	3600
+lease_renewable	true
+password       	dfa80eea-ccbe-b228-ebf7-e2f62b245e71
+username       	vault-root-1434647667-9313
+```
+
+By reading from the `creds/readonly` path, Vault has generated a new
+set of credentials using the `readonly` role configuration. Here we
+see the dynamically generated username and password, along with a one
+hour lease.
+
+Using ACLs, it is possible to restrict using the `cassandra` backend such
+that trusted operators can manage the role definitions, and both
+users and applications are restricted in the credentials they are
+allowed to read.
+
+If you get stuck at any time, simply run `vault path-help cassandra` or with a
+subpath for interactive help output.
+
+## API
+
+### /cassandra/config/connection
+#### POST
+
+<dl class="api">
+  <dt>Description</dt>
+  <dd>
+    Configures the connection information used to communicate with Cassandra.
+    TLS works as follows:<br /><br />
+    <ul>
+      <li>
+        • If `tls` is set to true, the connection will use TLS; this happens automatically if `pem_bundle`, `pem_json`, or `insecure_tls` is set
+      </li>
+      <li>
+        • If `insecure_tls` is set to true, the connection will not perform verification of the server certificate; this also sets `tls` to true
+      </li>
+      <li>
+        • If only `issuing_ca` is set in `pem_json`, or the only certificate in `pem_bundle` is a CA certificate, the given CA certificate will be used for server certificate verification; otherwise the system CA certificates will be used
+      </li>
+      <li>
+        • If `certificate` and `private_key` are set in `pem_bundle` or `pem_json`, client auth will be turned on for the connection
+      </li>
+    </ul>
+    `pem_bundle` should be a PEM-concatenated bundle of a private key + client certificate, an issuing CA certificate, or both. `pem_json` should contain the same information; for convenience, the JSON format is the same as that output by the issue command from the PKI backend.<br /><br />
+    This is a root protected endpoint.
+  </dd>
+
+  <dt>Method</dt>
+  <dd>POST</dd>
+
+  <dt>URL</dt>
+  <dd>`/cassandra/config/connection`</dd>
+
+  <dt>Parameters</dt>
+  <dd>
+    <ul>
+      <li>
+        <span class="param">hosts</span>
+        <span class="param-flags">required</span>
+        A set of comma-deliniated Cassandra hosts to connect to.
+      </li>
+      <li>
+        <span class="param">username</span>
+        <span class="param-flags">required</span>
+        The username to use for superuser access.
+      </li>
+      <li>
+        <span class="param">password</span>
+        <span class="param-flags">required</span>
+        The password corresponding to the given username.
+      </li>
+      <li>
+        <span class="param">tls</span>
+        <span class="param-flags">optional</span>
+        Whether to use TLS when connecting to Cassandra.
+      </li>
+      <li>
+        <span class="param">insecure_tls</span>
+        <span class="param-flags">optional</span>
+        Whether to skip verification of the server certificate when using TLS.
+      </li>
+      <li>
+        <span class="param">pem_bundle</span>
+        <span class="param-flags">optional</span>
+        Concatenated PEM blocks containing a certificate and private key;
+        a certificate, private key, and issuing CA certificate; or just a CA
+        certificate.
+      </li>
+      <li>
+        <span class="param">pem_json</span>
+        <span class="param-flags">optional</span>
+        JSON containing a certificate and private key;
+        a certificate, private key, and issuing CA certificate; or just a CA
+        certificate. For convenience format is the same as the output of the
+        `issue` command from the `pki` backend; see [the pki documentation](https://vaultproject.io/docs/secrets/pki/index.html).
+      </li>
+    </ul>
+  </dd>
+
+  <dt>Returns</dt>
+  <dd>
+    A `204` response code.
+  </dd>
+</dl>
+
+### /cassandra/roles/
+#### POST
+
+<dl class="api">
+  <dt>Description</dt>
+  <dd>
+    Creates or updates the role definition.
+  </dd>
+
+  <dt>Method</dt>
+  <dd>POST</dd>
+
+  <dt>URL</dt>
+  <dd>`/cassandra/roles/<name>`</dd>
+
+  <dt>Parameters</dt>
+  <dd>
+    <ul>
+      <li>
+        <span class="param">creation_cql</span>
+        <span class="param-flags">optional</span>
+        The CQL statements executed to create and configure the new user.
+        Must be semi-colon separated. The '{{username}}' and '{{password}}'
+        values will be substituted; it is required that these parameters are
+        in single quotes. The default creates a non-superuser user with
+        no authorization grants.
+      </li>
+      <li>
+        <span class="param">rollback_cql</span>
+        <span class="param-flags">optional</span>
+        The CQL statements executed to attempt a rollback if an error is
+        encountered during user creation. The default is to delete the user.
+        Must be semi-colon separated. The '{{username}}' and '{{password}}'
+        values will be substituted; it is required that these parameters are
+        in single quotes.
+      </li>
+      <li>
+        <span class="param">lease</span>
+        <span class="param-flags">optional</span>
+        The lease value provided as a string duration
+        with time suffix. Hour is the largest suffix.
+      </li>
+      <li>
+        <span class="param">lease_grace_period</span>
+        <span class="param-flags">optional</span>
+        The lease grace period (time before revocation after the lease has
+        expired) provided as a string duration with time suffix. Hour is the
+        largest suffix.
+      </li>
+    </ul>
+  </dd>
+
+  <dt>Returns</dt>
+  <dd>
+    A `204` response code.
+  </dd>
+</dl>
+
+#### GET
+
+<dl class="api">
+  <dt>Description</dt>
+  <dd>
+    Queries the role definition.
+  </dd>
+
+  <dt>Method</dt>
+  <dd>GET</dd>
+
+  <dt>URL</dt>
+  <dd>`/cassandra/roles/<name>`</dd>
+
+  <dt>Parameters</dt>
+  <dd>
+     None
+  </dd>
+
+  <dt>Returns</dt>
+  <dd>
+
+    ```javascript
+    {
+        "data": {
+            "creation_cql": "CREATE USER...",
+            "revocation_cql": "DROP USER...",
+            "lease": "12h",
+            "lease_grace_period": "1h"
+        }
+    }
+    ```
+
+  </dd>
+</dl>
+
+
+#### DELETE
+
+<dl class="api">
+  <dt>Description</dt>
+  <dd>
+    Deletes the role definition.
+  </dd>
+
+  <dt>Method</dt>
+  <dd>DELETE</dd>
+
+  <dt>URL</dt>
+  <dd>`/cassandra/roles/<name>`</dd>
+
+  <dt>Parameters</dt>
+  <dd>
+     None
+  </dd>
+
+  <dt>Returns</dt>
+  <dd>
+    A `204` response code.
+  </dd>
+</dl>
+
+### /cassandra/creds/
+#### GET
+
+<dl class="api">
+  <dt>Description</dt>
+  <dd>
+    Generates a new set of dynamic credentials based on the named role.
+  </dd>
+
+  <dt>Method</dt>
+  <dd>GET</dd>
+
+  <dt>URL</dt>
+  <dd>`/cassandra/creds/<name>`</dd>
+
+  <dt>Parameters</dt>
+  <dd>
+     None
+  </dd>
+
+  <dt>Returns</dt>
+  <dd>
+
+    ```javascript
+    {
+        "data": {
+            "username": "vault-root-1430158508-126",
+            "password": "132ae3ef-5a64-7499-351e-bfe59f3a2a21"
+        }
+    }
+    ```
+
+  </dd>
+</dl>
diff --git a/website/source/docs/secrets/consul/index.html.md b/website/source/docs/secrets/consul/index.html.md
new file mode 100644
index 000000000..05fb10083
--- /dev/null
+++ b/website/source/docs/secrets/consul/index.html.md
@@ -0,0 +1,252 @@
+---
+layout: "docs"
+page_title: "Secret Backend: Consul"
+sidebar_current: "docs-secrets-consul"
+description: |-
+  The Consul secret backend for Vault generates tokens for Consul dynamically.
+---
+
+# Consul Secret Backend
+
+Name: `consul`
+
+The Consul secret backend for Vault generates
+[Consul](http://consul.io)
+API tokens dynamically based on Consul ACL policies.
+
+This page will show a quick start for this backend. For detailed documentation
+on every path, use `vault path-help` after mounting the backend.
+
+## Quick Start
+
+The first step to using the consul backend is to mount it.
+Unlike the `generic` backend, the `consul` backend is not mounted by default.
+
+```
+$ vault mount consul
+Successfully mounted 'consul' at 'consul'!
+```
+
+Next, we must configure Vault to know how to contact Consul.
+This is done by writing the access information:
+
+```
+$ vault write consul/config/access address=127.0.0.1:8500 token=root
+Success! Data written to: consul/config/access
+```
+
+In this case, we've configured Vault to connect to Consul
+on the default port with the loopback address. We've also provided
+an ACL token to use with the `token` parameter. Vault must have a management
+type token so that it can create and revoke ACL tokens.
+
+The next step is to configure a role. A role is a logical name that maps
+to a role used to generated those credentials. For example, lets create
+a "readonly" role:
+
+```
+POLICY='key "" { policy = "read" }'
+$ echo $POLICY | base64 | vault write consul/roles/readonly policy=-
+Success! Data written to: consul/roles/readonly
+```
+
+The backend expects the policy to be base64 encoded, so we need to encode
+it properly before writing. The policy language is
+[documented by Consul](https://consul.io/docs/internals/acl.html), but we've defined a read-only policy.
+
+To generate a new set Consul ACL token, we simply read from that role:
+
+```
+$ vault read consul/creds/readonly
+Key           	Value
+lease_id      	consul/creds/readonly/c7a3bd77-e9af-cfc4-9cba-377f0ef10e6c
+lease_duration	3600
+token         	973a31ea-1ec4-c2de-0f63-623f477c2510
+```
+
+Here we can see that Vault has generated a new Consul ACL token for us.
+We can test this token out, and verify that it is read-only:
+
+```
+$ curl 127.0.0.1:8500/v1/kv/foo?token=973a31ea-1ec4-c2de-0f63-623f477c25100
+[{"CreateIndex":12,"ModifyIndex":53,"LockIndex":4,"Key":"foo","Flags":3304740253564472344,"Value":"YmF6"}]
+
+$ curl -X PUT -d 'test' 127.0.0.1:8500/v1/kv/foo?token=973a31ea-1ec4-c2de-0f63-623f477c2510
+Permission denied
+```
+
+## API
+
+### /consul/config/access
+#### POST
+
+<dl class="api">
+  <dt>Description</dt>
+  <dd>
+    Configures the access information for Consul.
+    This is a root protected endpoint.
+  </dd>
+
+  <dt>Method</dt>
+  <dd>POST</dd>
+
+  <dt>URL</dt>
+  <dd>`/consul/config/access`</dd>
+
+  <dt>Parameters</dt>
+  <dd>
+    <ul>
+      <li>
+        <span class="param">address</span>
+        <span class="param-flags">required</span>
+        The address of the Consul instance, provided as host:port
+      </li>
+      <li>
+        <span class="param">scheme</span>
+        <span class="param-flags">optional</span>
+        The URL scheme to use. Defaults to HTTP, as Consul does not expose HTTPS by default.
+      </li>
+      <li>
+        <span class="param">token</span>
+        <span class="param-flags">required</span>
+        The Consul ACL token to use. Must be a management type token.
+      </li>
+    </ul>
+  </dd>
+
+  <dt>Returns</dt>
+  <dd>
+    A `204` response code.
+  </dd>
+</dl>
+
+### /consul/roles/
+#### POST
+
+<dl class="api">
+  <dt>Description</dt>
+  <dd>
+    Creates or updates the Consul role definition.
+  </dd>
+
+  <dt>Method</dt>
+  <dd>POST</dd>
+
+  <dt>URL</dt>
+  <dd>`/consul/roles/<name>`</dd>
+
+  <dt>Parameters</dt>
+  <dd>
+    <ul>
+      <li>
+        <span class="param">policy</span>
+        <span class="param-flags">required</span>
+        The base64 encoded Consul ACL policy. This is documented in [more detail here](https://consul.io/docs/internals/acl.html).
+      </li>
+      <li>
+        <span class="param">lease</span>
+        <span class="param-flags">optional</span>
+        The lease value provided as a string duration with time suffix. Hour is the largest suffix.
+      </li>
+    </ul>
+  </dd>
+
+  <dt>Returns</dt>
+  <dd>
+    A `204` response code.
+  </dd>
+</dl>
+
+#### GET
+
+<dl class="api">
+  <dt>Description</dt>
+  <dd>
+    Queries a Consul role definition.
+  </dd>
+
+  <dt>Method</dt>
+  <dd>GET</dd>
+
+  <dt>URL</dt>
+  <dd>`/consul/roles/<name>`</dd>
+
+  <dt>Parameters</dt>
+  <dd>
+     None
+  </dd>
+
+  <dt>Returns</dt>
+  <dd>
+
+    ```javascript
+    {
+        "data": {
+            "policy": "abcdef="
+        }
+    }
+    ```
+
+  </dd>
+</dl>
+
+#### Delete
+
+<dl class="api">
+  <dt>Description</dt>
+  <dd>
+    Deletes a Consul role definition.
+  </dd>
+
+  <dt>Method</dt>
+  <dd>DELETE</dd>
+
+  <dt>URL</dt>
+  <dd>`/consul/roles/<name>`</dd>
+
+  <dt>Parameters</dt>
+  <dd>
+     None
+  </dd>
+
+  <dt>Returns</dt>
+  <dd>
+    A `204` response code.
+  </dd>
+</dl>
+
+### /consul/creds/
+#### GET
+
+<dl class="api">
+  <dt>Description</dt>
+  <dd>
+    Generates a dynamic Consul token based on the role definition.
+  </dd>
+
+  <dt>Method</dt>
+  <dd>GET</dd>
+
+  <dt>URL</dt>
+  <dd>`/consul/creds/<name>`</dd>
+
+  <dt>Parameters</dt>
+  <dd>
+     None
+  </dd>
+
+  <dt>Returns</dt>
+  <dd>
+
+    ```javascript
+    {
+        "data": {
+            "token": "973a31ea-1ec4-c2de-0f63-623f477c2510"
+        }
+    }
+    ```
+
+  </dd>
+</dl>
+
+
diff --git a/website/source/docs/secrets/custom.html.md b/website/source/docs/secrets/custom.html.md
new file mode 100644
index 000000000..ef3f976e7
--- /dev/null
+++ b/website/source/docs/secrets/custom.html.md
@@ -0,0 +1,19 @@
+---
+layout: "docs"
+page_title: "Secret Backend: Custom"
+sidebar_current: "docs-secrets-custom"
+description: |-
+  Create custom secret backends for Vault.
+---
+
+# Custom Secret Backends
+
+Vault doesn't currently support the creation of custom secret backends.
+The primary reason is because we want to ensure the core of Vault is
+secure before attempting any sort of plug-in system. We're interested
+in supporting custom secret backends, but don't yet have a clear strategy
+or timeline to do.
+
+In the mean time, you can use the
+[generic backend](/docs/secrets/generic/index.html) to support custom
+data with custom leases.
diff --git a/website/source/docs/secrets/generic/index.html.md b/website/source/docs/secrets/generic/index.html.md
new file mode 100644
index 000000000..ad4742b47
--- /dev/null
+++ b/website/source/docs/secrets/generic/index.html.md
@@ -0,0 +1,50 @@
+---
+layout: "docs"
+page_title: "Secret Backend: Generic"
+sidebar_current: "docs-secrets-generic"
+description: |-
+  The generic secret backend can store arbitrary secrets.
+---
+
+# Generic Secret Backend
+
+Name: `generic`
+
+The generic secret backend is used to store arbitrary secrets within
+the configured physical storage for Vault. If you followed along with
+the getting started guide, you interacted with a generic secret backend
+via the `secret/` prefix that Vault mounts by default.
+
+Writing to a key in the `secret/` backend will replace the old value,
+the sub-fields are not merged together.
+
+## Quick Start
+
+The generic backend allows for writing keys with arbitrary values. The
+only value that is special is the `lease` key, which can be provided with
+any key to restrict the lease time of the secret. This is useful to ensure
+clients periodically renew so that key rolling can be time bounded.
+
+As an example, we can write a new key "foo" to the generic backend
+mounted at "secret/" by default:
+
+```
+$ vault write secret/foo zip=zap lease=1h
+Success! Data written to: secret/foo
+```
+
+This writes the key with the "zip" field set to "zap" and a one hour lease. We can test
+this by doing a read:
+
+```
+$ vault read secret/foo
+Key           	Value
+lease_id      	secret/foo/e4514713-d5d9-fb14-4177-97a7f7f64518
+lease_duration	3600
+lease         	1h
+zip           	zap
+```
+
+As expected, we get the value previously set back as well as our custom lease.
+The lease_duration has been set to 3600 seconds, or one hour as specified.
+
diff --git a/website/source/docs/secrets/index.html.md b/website/source/docs/secrets/index.html.md
new file mode 100644
index 000000000..6e4fd3667
--- /dev/null
+++ b/website/source/docs/secrets/index.html.md
@@ -0,0 +1,75 @@
+---
+layout: "docs"
+page_title: "Secret Backends"
+sidebar_current: "docs-secrets"
+description: |-
+  Secret backends are mountable backends that store or generate secrets in Vault.
+---
+
+# Secret Backends
+
+Secret backends are the components in Vault which store and generate
+secrets.
+
+Some secret backends, such as "generic", simply store and read
+secrets verbatim. Other secret backends, such as "aws", create _dynamic
+secrets_: secrets that are made on demand.
+
+Secret backends are part of the
+[mount system](#)
+in Vault. They behave very similarly to a virtual filesystem:
+any read/write/delete is sent to the secret backend, and the secret
+backend can choose to react to that operation however it sees fit.
+
+For example, the "generic" backend passes through any operation back
+to the configured storage backend for Vault. A "read" turns into a
+"read" of the storage backend at the same path, a "write" turns into
+a write, etc. This is a lot like a normal filesystem.
+
+The "aws" backend, on the other hand, behaves differently. When you
+write to `aws/config/root`, it expects a certain format and stores that
+information as configuration. You can't read from this path. When you
+read from `aws/<name>`, it looks up an IAM policy named `<name>` and
+generates AWS access credentials on demand and returns them. It doesn't
+behave at all like a typical filesystem: you're not simply storing and
+retrieving values, you're interacting with an API.
+
+## Mounting/Unmounting Secret Backends
+
+Secret backends can be mounted/unmounted using the CLI or the API.
+There are three operations that can be performed with a secret backend
+with regards to mounting:
+
+  * **Mount** - This mounts a new secret backend. Multiple secret
+    backends of the same type can be mounted at the same time by
+    specifying different mount points. By default, secret backends are
+    mounted to the same path as their name. This is what you want most
+    of the time.
+
+  * **Unmount** - This unmounts an existing secret backend. When a secret
+    backend is unmounted, all of its secrets are revoked (if they support
+    it), and all of the data stored for that backend in the physical storage
+    layer is deleted.
+
+  * **Remount** - This moves the mount point for an existing secret backend.
+    This revokes all secrets, since secret leases are tied to the path they
+    were created at. The data stored for the backend won't be deleted.
+
+Once a secret backend is mounted, you can interact with it directly
+at its mount point according to its own API. You can use the `vault path-help`
+system to determine the paths it responds to.
+
+## Barrier View
+
+An important concept around secret backends is that they receive a
+_barrier view_ to the configured Vault physical storage. This is a lot
+like a [chroot](http://en.wikipedia.org/wiki/Chroot).
+
+Whenever a secret backend is mounted, a random UUID is generated. This
+becomes the data root for that backend. Whenever that backend writes to
+the physical storage layer, it is prefixed with that UUID folder. Since
+the Vault storage layer doesn't support relative access (such as `..`),
+this makes it impossible for a mounted backend to access any other data.
+
+This is an important security feature in Vault: even a malicious backend
+can't access the data from any other backend.
diff --git a/website/source/docs/secrets/jwt/index.html.md b/website/source/docs/secrets/jwt/index.html.md
new file mode 100644
index 000000000..aecc94f9e
--- /dev/null
+++ b/website/source/docs/secrets/jwt/index.html.md
@@ -0,0 +1,259 @@
+# JWT Secret Backend
+
+Name: `jwt`
+
+The JWT secret backend for Vault generates JSON Web Tokens dynamically based on configured roles. This means services can get tokens needed for authentication without going through the usual manual process of generating a private key and signing the token and maintaining the private key's security. Vault's built-in authentication and authorization mechanisms provide the verification functionality.
+
+This page will show a quick start for this backend. For detailed documentation on every path, use `vault path-help` after mounting the backend.
+
+The JWT secret backend acts like the `transit` backend, it does not store any information.
+
+## Algorithms
+
+### RSA 
+* RS256
+* RS384
+* RS512
+
+These require a RSA private/public keypair for signing and verification.
+
+### ECDSA
+* EC256
+* EC384
+* EC512
+
+These require an ECDSA private/public keypair for signing and verification.
+
+### HMAC
+* HS256
+* HS384
+* HS512
+
+These require a shared secret for signing and verification.
+
+## Roles
+
+Roles are defined with the signing algorithm, the secret key or private key to be used, as well as allowing for default but optional JWT Token claims. Once you write a private key or a secret to the role, it CANNOT be read back out.
+
+## Quick Start
+
+The first step to using the jwt backend is to mount it.
+Unlike the `generic` backend, the `jwt` backend is not mounted by default.
+
+```text
+$ vault mount jwt
+Successfully mounted 'jwt' at 'jwt'!
+```
+
+The next step is to configure a role. A role is a logical name that maps
+to a few settings used to generated the tokens. For example, lets create
+a "webauth" role:
+
+```text
+$ vault write jwt/roles/webauth \
+    algorithm=RS256 \
+    key=@/path/to/private.key
+```
+
+Each role requires a secret or a private key to be associated against it.
+
+Generating a token requires passing of additional information so we use the
+"jwt/issue/ROLE" path.
+
+```text
+$ vault write jwt/issue/webauth \
+    issuer="Vault" \
+    audience="Vault Client" \
+    expiration="1538096292" \
+    claims=@extra.json
+```
+
+
+## API
+
+### /jwt/roles/
+#### POST
+
+<dl class="api">
+  <dt>Description</dt>
+  <dd>
+    Creates or updates a named role.
+  </dd>
+
+  <dt>Method</dt>
+  <dd>POST</dd>
+
+  <dt>URL</dt>
+  <dd>`/jwt/roles/<name>`</dd>
+
+  <dt>Parameters</dt>
+  <dd>
+    <ul>
+      <li>
+        <span class="param">algorithm</span>
+        <span class="param-flags">required</span>
+        The algorithm used by JWT to sign the token.
+      </li>
+      <li>
+        <span class="param">key</span>
+        <span class="param-flags">required</span>
+        The private key or string used to sign the token.
+      </li>
+      <li>
+        <span class="param">default_issuer</span>
+        <span class="param-flags">required</span>
+        The default issuer claim for the role, can be overridden at issue time.
+      </li>
+      <li>
+        <span class="param">default_subject</span>
+        <span class="param-flags">required</span>
+        The default subject claim for the role, can be overridden at issue time.
+      </li>
+      <li>
+        <span class="param">default_audience</span>
+        <span class="param-flags">required</span>
+        The default audience claim for the role, can be overridden at issue time.
+      </li>
+    </ul>
+  </dd>
+
+  <dt>Returns</dt>
+  <dd>
+    A `204` response code.
+  </dd>
+</dl>
+
+#### GET
+
+<dl class="api">
+  <dt>Description</dt>
+  <dd>
+    Queries a named role.
+  </dd>
+
+  <dt>Method</dt>
+  <dd>GET</dd>
+
+  <dt>URL</dt>
+  <dd>`/jwt/roles/<name>`</dd>
+
+  <dt>Parameters</dt>
+  <dd>
+    None
+  </dd>
+
+  <dt>Returns</dt>
+  <dd>
+
+    ```javascript
+    {
+        "data": {
+            "algorithm": "..."
+        }
+    }
+    ```
+
+  </dd>
+</dl>
+
+#### DELETE
+
+<dl class="api">
+  <dt>Description</dt>
+  <dd>
+    Deletes a named role.
+  </dd>
+
+  <dt>Method</dt>
+  <dd>DELETE</dd>
+
+  <dt>URL</dt>
+  <dd>`/jwt/roles/<name>`</dd>
+
+  <dt>Parameters</dt>
+  <dd>
+    None
+  </dd>
+
+  <dt>Returns</dt>
+  <dd>
+    A `204` response code.
+  </dd>
+</dl>
+
+
+### /jwt/issue/
+#### POST
+
+<dl class="api">
+  <dt>Description</dt>
+  <dd>
+    Generates a JWT token based on the named role.
+  </dd>
+
+  <dt>Method</dt>
+  <dd>GET</dd>
+
+  <dt>URL</dt>
+  <dd>`/jwt/issue/<role>`</dd>
+
+  <dt>Parameters</dt>
+  <dd>
+    <ul>
+      <li>
+        <span class="param">issuer</span>
+        <span class="param-flags">optional</span>
+        The Issuer of the token.
+      </li>
+      <li>
+        <span class="param">audience</span>
+        <span class="param-flags">optional</span>
+        The Audience of the token.
+      </li>
+      <li>
+        <span class="param">subject</span>
+        <span class="param-flags">optional</span>
+        The Subject of the token.
+      </li>
+      <li>
+        <span class="param">expiration</span>
+        <span class="param-flags">optional</span>
+        The expiration of the token, expressed in seconds (unix time).
+      </li>
+      <li>
+        <span class="param">issued_at</span>
+        <span class="param-flags">optional</span>
+        The issued at time of the token, expressed in seconds (unix time). (Default: current time)
+      </li>
+      <li>
+        <span class="param">not_before</span>
+        <span class="param-flags">optional</span>
+        Not Before: the time at which the token is not useful before. Expressed as seconds, unix time. (Default: current time)
+      </li>
+      <li>
+        <span class="param">jti</span>
+        <span class="param-flags">optional</span>
+        JSONWebToken Identifier. Unique ID useful for preventing replay attacks. (Default: Random UUID)
+      </li>
+      <li>
+        <span class="param">claims</span>
+        <span class="param-flags">optional</span>
+        Should be a JSON Object of additional key/values you want in the token.
+      </li>
+    </ul>
+  </dd>
+
+  <dt>Returns</dt>
+  <dd>
+
+    ```javascript
+    {
+        "data": {
+            "jti": "...",
+            "token": "..."
+        }
+    }
+    ```
+
+  </dd>
+</dl>
diff --git a/website/source/docs/secrets/mysql/index.html.md b/website/source/docs/secrets/mysql/index.html.md
new file mode 100644
index 000000000..d45c12a0b
--- /dev/null
+++ b/website/source/docs/secrets/mysql/index.html.md
@@ -0,0 +1,307 @@
+---
+layout: "docs"
+page_title: "Secret Backend: MySQL"
+sidebar_current: "docs-secrets-mysql"
+description: |-
+  The MySQL secret backend for Vault generates database credentials to access MySQL.
+---
+
+# MySQL Secret Backend
+
+Name: `mysql`
+
+The MySQL secret backend for Vault generates database credentials
+dynamically based on configured roles. This means that services that need
+to access a database no longer need to hardcode credentials: they can request
+them from Vault, and use Vault's leasing mechanism to more easily roll keys.
+
+Additionally, it introduces a new ability: with every service accessing
+the database with unique credentials, it makes auditing much easier when
+questionable data access is discovered: you can track it down to the specific
+instance of a service based on the SQL username.
+
+Vault makes use of its own internal revocation system to ensure that users
+become invalid within a reasonable time of the lease expiring.
+
+This page will show a quick start for this backend. For detailed documentation
+on every path, use `vault path-help` after mounting the backend.
+
+## Quick Start
+
+The first step to using the mysql backend is to mount it.
+Unlike the `generic` backend, the `mysql` backend is not mounted by default.
+
+```
+$ vault mount mysql
+Successfully mounted 'mysql' at 'mysql'!
+```
+
+Next, we must configure Vault to know how to connect to the MySQL
+instance. This is done by providing a DSN (Data Source Name):
+
+```
+$ vault write mysql/config/connection value="root:root@tcp(192.168.33.10:3306)/"
+Success! Data written to: mysql/config/connection
+```
+
+In this case, we've configured Vault with the user "root" and password "root,
+connecting to an instance at "192.168.33.10" on port 3306. It is not necessary
+that Vault has the root user, but the user must have privileges to create
+other users, namely the `GRANT OPTION` privilege.
+
+Optionally, we can configure the lease settings for credentials generated
+by Vault. This is done by writing to the `config/lease` key:
+
+```
+$ vault write mysql/config/lease lease=1h lease_max=24h
+Success! Data written to: mysql/config/lease
+```
+
+This restricts each credential to being valid or leased for 1 hour
+at a time, with a maximum use period of 24 hours. This forces an
+application to renew their credentials at least hourly, and to recycle
+them once per day.
+
+The next step is to configure a role. A role is a logical name that maps
+to a policy used to generated those credentials. For example, lets create
+a "readonly" role:
+
+```
+$ vault write mysql/roles/readonly sql="CREATE USER '{{name}}'@'%' IDENTIFIED BY '{{password}}';GRANT SELECT ON *.* TO '{{name}}'@'%';"
+Success! Data written to: mysql/roles/readonly
+```
+
+By writing to the `roles/readonly` path we are defining the `readonly` role.
+This role will be created by evaluating the given `sql` statements. By
+default, the `{{name}}` and `{{password}}` fields will be populated by
+Vault with dynamically generated values. This SQL statement is creating
+the named user, and then granting it `SELECT` or read-only privileges
+to tables in the database. More complex `GRANT` queries can be used to
+customize the privileges of the role. See the [MySQL manual](https://dev.mysql.com/doc/refman/5.7/en/grant.html)
+for more information.
+
+To generate a new set of credentials, we simply read from that role:
+
+```
+$ vault read mysql/creds/readonly
+Key           	Value
+lease_id      	mysql/creds/readonly/bd404e98-0f35-b378-269a-b7770ef01897
+lease_duration	3600
+password      	132ae3ef-5a64-7499-351e-bfe59f3a2a21
+username      	root-aefa635a-18
+```
+
+By reading from the `creds/readonly` path, Vault has generated a new
+set of credentials using the `readonly` role configuration. Here we
+see the dynamically generated username and password, along with a one
+hour lease.
+
+Using ACLs, it is possible to restrict using the mysql backend such
+that trusted operators can manage the role definitions, and both
+users and applications are restricted in the credentials they are
+allowed to read.
+
+## API
+
+### /mysql/config/connection
+#### POST
+
+<dl class="api">
+  <dt>Description</dt>
+  <dd>
+    Configures the connection DSN used to communicate with MySQL.
+    This is a root protected endpoint.
+  </dd>
+
+  <dt>Method</dt>
+  <dd>POST</dd>
+
+  <dt>URL</dt>
+  <dd>`/mysql/config/connection`</dd>
+
+  <dt>Parameters</dt>
+  <dd>
+    <ul>
+      <li>
+        <span class="param">value</span>
+        <span class="param-flags">required</span>
+        The MySQL DSN
+      </li>
+    </ul>
+  </dd>
+
+  <dt>Returns</dt>
+  <dd>
+    A `204` response code.
+  </dd>
+</dl>
+
+### /mysql/config/lease
+#### POST
+
+<dl class="api">
+  <dt>Description</dt>
+  <dd>
+    Configures the lease settings for generated credentials.
+    If not configured, leases default to 1 hour. This is a root
+    protected endpoint.
+  </dd>
+
+  <dt>Method</dt>
+  <dd>POST</dd>
+
+  <dt>URL</dt>
+  <dd>`/mysql/config/lease`</dd>
+
+  <dt>Parameters</dt>
+  <dd>
+    <ul>
+      <li>
+        <span class="param">lease</span>
+        <span class="param-flags">required</span>
+        The lease value provided as a string duration
+        with time suffix. Hour is the largest suffix.
+      </li>
+      <li>
+        <span class="param">lease_max</span>
+        <span class="param-flags">required</span>
+        The maximum lease value provided as a string duration
+        with time suffix. Hour is the largest suffix.
+      </li>
+    </ul>
+  </dd>
+
+  <dt>Returns</dt>
+  <dd>
+    A `204` response code.
+  </dd>
+</dl>
+
+### /mysql/roles/
+#### POST
+
+<dl class="api">
+  <dt>Description</dt>
+  <dd>
+    Creates or updates the role definition.
+  </dd>
+
+  <dt>Method</dt>
+  <dd>POST</dd>
+
+  <dt>URL</dt>
+  <dd>`/mysql/roles/<name>`</dd>
+
+  <dt>Parameters</dt>
+  <dd>
+    <ul>
+      <li>
+        <span class="param">sql</span>
+        <span class="param-flags">required</span>
+        The SQL statements executed to create and configure the role.
+        Must be semi-colon separated. The '{{name}}' and '{{password}}'
+        values will be substituted.
+      </li>
+    </ul>
+  </dd>
+
+  <dt>Returns</dt>
+  <dd>
+    A `204` response code.
+  </dd>
+</dl>
+
+#### GET
+
+<dl class="api">
+  <dt>Description</dt>
+  <dd>
+    Queries the role definition.
+  </dd>
+
+  <dt>Method</dt>
+  <dd>GET</dd>
+
+  <dt>URL</dt>
+  <dd>`/mysql/roles/<name>`</dd>
+
+  <dt>Parameters</dt>
+  <dd>
+     None
+  </dd>
+
+  <dt>Returns</dt>
+  <dd>
+
+    ```javascript
+    {
+        "data": {
+            "sql": "CREATE USER..."
+        }
+    }
+    ```
+
+  </dd>
+</dl>
+
+
+#### DELETE
+
+<dl class="api">
+  <dt>Description</dt>
+  <dd>
+    Deletes the role definition.
+  </dd>
+
+  <dt>Method</dt>
+  <dd>DELETE</dd>
+
+  <dt>URL</dt>
+  <dd>`/mysql/roles/<name>`</dd>
+
+  <dt>Parameters</dt>
+  <dd>
+     None
+  </dd>
+
+  <dt>Returns</dt>
+  <dd>
+    A `204` response code.
+  </dd>
+</dl>
+
+### /mysql/creds/
+#### GET
+
+<dl class="api">
+  <dt>Description</dt>
+  <dd>
+    Generates a new set of dynamic credentials based on the named role.
+  </dd>
+
+  <dt>Method</dt>
+  <dd>GET</dd>
+
+  <dt>URL</dt>
+  <dd>`/mysql/creds/<name>`</dd>
+
+  <dt>Parameters</dt>
+  <dd>
+     None
+  </dd>
+
+  <dt>Returns</dt>
+  <dd>
+
+    ```javascript
+    {
+        "data": {
+            "username": "root-aefa635a-18",
+            "password": "132ae3ef-5a64-7499-351e-bfe59f3a2a21"
+        }
+    }
+    ```
+
+  </dd>
+</dl>
+
diff --git a/website/source/docs/secrets/pki/index.html.md b/website/source/docs/secrets/pki/index.html.md
new file mode 100644
index 000000000..85e3d9c88
--- /dev/null
+++ b/website/source/docs/secrets/pki/index.html.md
@@ -0,0 +1,649 @@
+---
+layout: "docs"
+page_title: "Secret Backend: PKI"
+sidebar_current: "docs-secrets-pki"
+description: |-
+  The PKI secret backend for Vault generates TLS certificates.
+---
+
+# PKI Secret Backend
+
+Name: `pki`
+
+The PKI secret backend for Vault generates X.509 certificates dynamically based on configured roles. This means services can get certificates needed for both client and server authentication without going through the usual manual process of generating a private key and CSR, submitting to a CA, and waiting for a verification and signing process to complete. Vault's built-in authentication and authorization mechanisms provide the verification functionality.
+
+By keeping leases relatively short, revocations are less likely to be needed, keeping CRLs short and helping the backend scale to large workloads. This in turn allows each instance of a running application to have a unique certificate, eliminating sharing and the accompanying pain of revocation and rollover.
+
+In addition, by allowing revocation to mostly be forgone, this backend allows for ephemeral certificates; certificates can be fetched and stored in memory upon application startup and discarded upon shutdown, without ever being written to disk.
+
+This page will show a quick start for this backend. For detailed documentation on every path, use `vault path-help` after mounting the backend.
+
+## Considerations
+
+To successfully deploy this backend, there are a number of important considerations to be aware of, as well as some preparatory steps that should be undertaken. You should read all of these *before* using this backend or generating the CA to use with this backend.
+
+### Never use root CAs
+
+Vault storage is secure, but not as secure as a piece of paper in a bank vault. It is, after all, networked software. Your long-lived self-signed root CA's private key should instead be used to issue a shorter-lived intermediate CA certificate, and this is what you should put into Vault. This aligns with industry best practices.
+
+### One CA Certificate, One Backend
+
+In order to vastly simplify both the configuration and codebase of the PKI backend, only one CA certificate is allowed per backend. If you want to issue certificates from multiple CAs, mount the PKI backend at multiple mount points with separate CA certificates in each.
+
+This also provides a convenient method of switching to a new CA certificate while keeping CRLs valid from the old CA certificate; simply mount a new backend and issue from there.
+
+### Keep certificate lifetimes short, for CRL's sake
+
+This backend aligns with Vault's philosophy of short-lived secrets. As such it is not expected that CRLs will grow large; the only place a private key is ever returned is to the requesting client (this backend does *not* store generated private keys). In most cases, if the key is lost, the certificate can simply be ignored, as it will expire shortly.
+
+If a certificate must truly be revoked, the normal Vault revocation function can be used; alternately a root token can be used to revoke the certificate using the certificate's serial number. Any revocation action will cause the CRL to be regenerated. When the CRL is regenerated, any expired certificates are removed from the CRL (and any revoked, expired certificate are removed from backend storage).
+
+This backend does not support multiple CRL endpoints with sliding date windows; often such mechanisms will have the transition point a few days apart, but this gets into the expected realm of the actual certificate validity periods issued from this backend. A good rule of thumb for this backend would be to simply not issue certificates with a validity period greater than your maximum comfortable CRL lifetime. Alternately, you can control CRL caching behavior on the client to ensure that checks happen more often.
+
+Often multiple endpoints are used in case a single CRL endpoint is down so that clients don't have to figure out what to do with a lack of response. Run Vault in HA mode, and the CRL endpoint should be available even if a particular node is down.
+
+### You must configure CRL information *in advance*
+
+This backend serves CRLs from a predictable location. That location must be encoded into your CA certificate if you want to allow applications to use the CRL endpoint encoded in certificates to find the CRL. Instructions for doing so are below. If you need to adjust this later, you will have to generate a new CA certificate using the same private key if you want to keep validity for already-issued certificates.
+
+### No OCSP support, yet
+
+Vault's architecture does not currently allow for a binary protocol such as OCSP to be supported by a backend. As such, you should configure your software to use CRLs for revocation information, with a caching lifetime that feels good to you. Since you are following the advice above about keeping lifetimes short (right?), CRLs should not grow too large.
+
+## Quick Start
+
+### CA certificate
+
+In order for this backend to serve CRL information at the expected location, you will need to generate your CA certificate with this information. For OpenSSL, this means putting a value in the CA section with the appropriate URL; in this example the PKI backend is mounted at `pki`:
+
+```text
+crlDistributionPoints = URI:https://vault.example.com:8200/v1/pki/crl
+```
+
+Adjust the URI as appropriate.
+
+### Vault
+
+The first step to using the PKI backend is to mount it. Unlike the `generic` backend, the `pki` backend is not mounted by default.
+
+```text
+$ vault mount pki
+Successfully mounted 'pki' at 'pki'!
+```
+
+Next, Vault must be configured with a root certificate and associated private key. This is done by writing the contents of a file or *stdin*:
+
+```text
+$ vault write pki/config/ca pem_bundle="@ca_bundle.pem"
+Success! Data written to: pki/config/ca
+```
+
+or
+
+```
+$ cat bundle.pem | vault write pki/config/ca pem_bundle="-"
+Success! Data written to: pki/config/ca
+```
+
+Although in this example the value being piped into *stdin* could be passed directly into the Vault CLI command, a more complex usage might be to use [Ansible](http://www.ansible.com) to securely store the certificate and private key in an `ansible-vault` file, then have an `ansible-playbook` command decrypt this value and pass it in to Vault.
+
+The next step is to configure a role. A role is a logical name that maps to a policy used to generated those credentials. For example, let's create an "example-dot-com" role:
+
+```text
+$ vault write pki/roles/example-dot-com \
+    allowed_base_domain="example.com" \
+    allow_subdomains="true" lease_max="72h"
+Success! Data written to: pki/roles/example-dot-com
+```
+
+By writing to the `roles/example-dot-com` path we are defining the `example-dot-com` role. To generate a new set of credentials, we simply write to the `issue` endpoint with that role name: Vault is now configured to create and manage certificates!
+
+```text
+$ vault write pki/issue/example-dot-com common_name=blah.example.com
+Key            	Value
+lease_id       	pki/issue/example-dot-com/819393b5-e1a1-9efd-b72f-4dc3a1972e31
+lease_duration 	259200
+lease_renewable	false
+certificate    	-----BEGIN CERTIFICATE-----
+MIIECDCCAvKgAwIBAgIUXmLrLkTdBIOOIYg2/BXO7docKfUwCwYJKoZIhvcNAQEL
+...
+az3gfwlOqVTdgi/ZVAtIzhSEJ0OY136bq4NOaw==
+-----END CERTIFICATE-----
+issuing_ca      -----BEGIN CERTIFICATE-----
+MIIDUTCCAjmgAwIBAgIJAKM+z4MSfw2mMA0GCSqGSIb3DQEBCwUAMBsxGTAXBgNV
+...
+-----END CERTIFICATE-----
+private_key    	-----BEGIN RSA PRIVATE KEY-----
+MIIEowIBAAKCAQEA0cczc7Y2yIu7aD/IaDi23Io+tvvDS9XaXXDUFW1kqd58P83r
+...
+3xhCNnZ3CMQaM2I48sloVK/XoikMLb5MZwOUQn/V+TrhWP4Lu7qD
+-----END RSA PRIVATE KEY-----
+serial         	5e:62:eb:2e:44:dd:04:83:8e:21:88:36:fc:15:ce:ed:da:1c:29:f5
+```
+
+Note that this is a write, not a read, to allow values to be passed in at request time.
+
+Vault has now generated a new set of credentials using the `example-dot-com` role configuration. Here we see the dynamically generated private key and certificate. The issuing CA certificate is returned as well.
+
+Using ACLs, it is possible to restrict using the pki backend such that trusted operators can manage the role definitions, and both users and applications are restricted in the credentials they are allowed to read.
+
+If you get stuck at any time, simply run `vault path-help pki` or with a subpath for interactive help output.
+
+## API
+
+### /pki/ca(/pem)
+#### GET
+
+<dl class="api">
+  <dt>Description</dt>
+  <dd>
+    Retrieves the CA certificate *in raw DER-encoded form*.
+    This is a bare endpoint that does not return a
+    standard Vault data structure. If `/pem` is added to the
+    endpoint, the CA certificate is returned in PEM format.
+    <br /><br />This is an unauthenticated endpoint.
+  </dd>
+
+  <dt>Method</dt>
+  <dd>GET</dd>
+
+  <dt>URL</dt>
+  <dd>`/pki/ca(/pem)`</dd>
+
+  <dt>Parameters</dt>
+  <dd>
+     None
+  </dd>
+
+  <dt>Returns</dt>
+  <dd>
+
+    ```
+    <binary DER-encoded certficiate>
+    ```
+
+  </dd>
+</dl>
+
+### /pki/cert/
+#### GET
+
+<dl class="api">
+  <dt>Description</dt>
+  <dd>
+    Retrieves one of a selection of certificates. Valid values: `ca`
+    for the CA certificate, `crl` for the current CRL, or a serial
+    number in either hyphen-separated or colon-separated octal format.
+    This endpoint returns the certificate in PEM formatting in the
+    `certificate` key of the JSON object.
+    <br /><br />This is an unauthenticated endpoint.
+  </dd>
+
+  <dt>Method</dt>
+  <dd>GET</dd>
+
+  <dt>URL</dt>
+  <dd>`/pki/cert/<serial>`</dd>
+
+  <dt>Parameters</dt>
+  <dd>
+     None
+  </dd>
+
+  <dt>Returns</dt>
+  <dd>
+
+    ```javascript
+    {
+        "data": {
+            "certificate": "-----BEGIN CERTIFICATE-----\nMIIGmDCCBYCgAwIBAgIHBzEB3fTzhTANBgkqhkiG9w0BAQsFADCBjDELMAkGA1UE\n..."
+        }
+    }
+    ...
+    ```
+
+  </dd>
+</dl>
+
+### /pki/config/ca
+#### POST
+
+<dl class="api">
+  <dt>Description</dt>
+  <dd>
+    A PEM file containing the issuing CA certificate
+    and its private key, concatenated.
+    <br /><br />This is a root-protected endpoint.
+    <br /><br />The information can be provided from a file via a `curl`
+    command similar to the following:<br/>
+
+    ```text
+    curl -X POST --data "@cabundle.json" http://127.0.0.1:8200/v1/pki/config/ca -H X-Vault-Token:06b9d...
+    ```
+
+    Note that if you provide the data through the HTTP API it must be
+    JSON-formatted, with newlines replaced with `\n`, like so:
+
+    ```text
+    { "pem_bundle": "-----BEGIN RSA PRIVATE KEY-----\n...\n-----END CERTIFICATE-----" }
+    ```
+  </dd>
+
+  <dt>Method</dt>
+  <dd>POST</dd>
+
+  <dt>URL</dt>
+  <dd>`/pki/config/ca`</dd>
+
+  <dt>Parameters</dt>
+  <dd>
+    <ul>
+      <li>
+        <span class="param">pem_bundle</span>
+        <span class="param-flags">required</span>
+        The key and certificate concatenated in PEM format.
+      </li>
+    </ul>
+  </dd>
+
+  <dt>Returns</dt>
+  <dd>
+    A `204` response code.
+  </dd>
+</dl>
+
+### /pki/crl(/pem)
+#### GET
+
+<dl class="api">
+  <dt>Description</dt>
+  <dd>
+    Retrieves the current CRL *in raw DER-encoded form*. This endpoint
+    is suitable for usage in the CRL Distribution Points extension in a
+    CA certificate. This is a bare endpoint that does not return a
+    standard Vault data structure. If `/pem` is added to the endpoint,
+    the CRL is returned in PEM format.
+    <br /><br />This is an unauthenticated endpoint.
+  </dd>
+
+  <dt>Method</dt>
+  <dd>GET</dd>
+
+  <dt>URL</dt>
+  <dd>`/pki/crl(/pem)`</dd>
+
+  <dt>Parameters</dt>
+  <dd>
+     None
+  </dd>
+
+  <dt>Returns</dt>
+  <dd>
+
+    ```
+    <binary DER-encoded CRL>
+    ```
+
+  </dd>
+</dl>
+
+### /pki/crl/rotate
+#### GET
+
+<dl class="api">
+  <dt>Description</dt>
+  <dd>
+  This endpoint forces a rotation of the CRL. This can be used
+  by administrators to cut the size of the CRL if it contains
+  a number of certificates that have now expired, but has
+  not been rotated due to no further certificates being revoked.
+  <br /><br />This is a root-protected endpoint.
+  </dd>
+
+  <dt>Method</dt>
+  <dd>GET</dd>
+
+  <dt>URL</dt>
+  <dd>`/pki/crl/rotate`</dd>
+
+  <dt>Parameters</dt>
+  <dd>
+     None
+  </dd>
+
+  <dt>Returns</dt>
+  <dd>
+
+  ```javascript
+  {
+      "data": {
+          "success": true
+      }
+  }
+  ```
+
+  </dd>
+</dl>
+
+### /pki/issue/
+#### POST
+
+<dl class="api">
+  <dt>Description</dt>
+  <dd>
+    Generates a new set of credentials (private key and
+    certificate) based on the named role. The issuing CA
+    certificate is returned as well, so that only the root CA
+    need be in a client's trust store.
+    <br /><br />*The private key is _not_ stored.
+    If you do not save the private key, you will need to
+    request a new certificate.*
+  </dd>
+
+  <dt>Method</dt>
+  <dd>POST</dd>
+
+  <dt>URL</dt>
+  <dd>`/pki/issue/<name>`</dd>
+
+  <dt>Parameters</dt>
+  <dd>
+    <ul>
+      <li>
+        <span class="param">common_name</span>
+        <span class="param-flags">required</span>
+        The requested CN for the certificate. If the CN is allowed
+        by role policy, it will be issued.
+      </li>
+      <li>
+        <span class="param">alt_names</span>
+        <span class="param-flags">optional</span>
+        Requested Subject Alternative Names, in a comma-delimited
+        list. If any requested names do not match role policy,
+        the entire request will be denied.
+      </li>
+      <li>
+        <span class="param">ip_sans</span>
+        <span class="param-flags">optional</span>
+        Requested IP Subject Alternative Names, in a comma-delimited
+        list. Only valid if the role allows IP SANs (which is the
+        default).
+      </li>
+      <li>
+      <span class="param">lease</span>
+      <span class="param-flags">optional</span>
+        Requested lease time. Cannot be greater than the role's
+        `lease_max` parameter. If not provided, the role's `lease`
+        value will be used.
+      </li>
+    </ul>
+  </dd>
+
+  <dt>Returns</dt>
+  <dd>
+
+  ```javascript
+  {
+      "lease_id": "pki/issue/test/7ad6cfa5-f04f-c62a-d477-f33210475d05",
+      "renewable": false,
+      "lease_duration": 21600,
+      "data": {
+          "certificate": "-----BEGIN CERTIFICATE-----\nMIIDzDCCAragAwIBAgIUOd0ukLcjH43TfTHFG9qE0FtlMVgwCwYJKoZIhvcNAQEL\n...\numkqeYeO30g1uYvDuWLXVA==\n-----END CERTIFICATE-----\n",
+          "issuing_ca": "-----BEGIN CERTIFICATE-----\nMIIDUTCCAjmgAwIBAgIJAKM+z4MSfw2mMA0GCSqGSIb3DQEBCwUAMBsxGTAXBgNV\n...\nG/7g4koczXLoUM3OQXd5Aq2cs4SS1vODrYmgbioFsQ3eDHd1fg==\n-----END CERTIFICATE-----\n",
+          "private_key": "-----BEGIN RSA PRIVATE KEY-----\nMIIEowIBAAKCAQEAnVHfwoKsUG1GDVyWB1AFroaKl2ImMBO8EnvGLRrmobIkQvh+\n...\nQN351pgTphi6nlCkGPzkDuwvtxSxiCWXQcaxrHAL7MiJpPzkIBq1\n-----END RSA PRIVATE KEY-----\n",
+          "serial": "39:dd:2e:90:b7:23:1f:8d:d3:7d:31:c5:1b:da:84:d0:5b:65:31:58"
+      },
+      "auth": null
+  }
+  ```
+
+  </dd>
+</dl>
+
+### /pki/revoke
+#### POST
+
+<dl class="api">
+  <dt>Description</dt>
+  <dd>
+    Revokes a certificate using its serial number. This is an
+    alternative option to the standard method of revoking
+    using Vault lease IDs. A successful revocation will
+    rotate the CRL.
+    <br /><br />This is a root-protected endpoint.
+  </dd>
+
+  <dt>Method</dt>
+  <dd>POST</dd>
+
+  <dt>URL</dt>
+  <dd>`/pki/revoke`</dd>
+
+  <dt>Parameters</dt>
+  <dd>
+    <ul>
+      <li>
+        <span class="param">serial_number</span>
+        <span class="param-flags">required</span>
+        The serial number of the certificate to revoke, in
+        hyphen-separated or colon-separated octal.
+      </li>
+    </ul>
+  </dd>
+
+  <dt>Returns</dt>
+  <dd>
+  ```javascript
+  {
+      "data": {
+          "revocation_time": 1433269787
+      }
+  }
+  ```
+  </dd>
+</dl>
+
+### /pki/roles/
+#### POST
+
+<dl class="api">
+  <dt>Description</dt>
+  <dd>
+    Creates or updates the role definition. Note that
+    the `allowed_base_domain`, `allow_token_displayname`,
+    `allow_subdomains`, and `allow_any_name` attributes
+    are additive; between them nearly and across multiple
+    roles nearly any issuing policy can be accommodated.
+    `server_flag`, `client_flag`, and `code_signing_flag`
+    are additive as well. If a client requests a
+    certificate that is not allowed by the CN policy in
+    the role, the request is denied.
+  </dd>
+
+  <dt>Method</dt>
+  <dd>POST</dd>
+
+  <dt>URL</dt>
+  <dd>`/pki/roles/<name>`</dd>
+
+  <dt>Parameters</dt>
+  <dd>
+    <ul>
+      <li>
+        <span class="param">lease</span>
+        <span class="param-flags">optional</span>
+        The lease value provided as a string duration
+        with time suffix. Hour is the largest suffix.
+        If not set, uses the value of `lease_max`.
+      </li>
+      <li>
+        <span class="param">lease_max</span>
+        <span class="param-flags">required</span>
+        The maximum lease value provided as a string duration
+        with time suffix. Hour is the largest suffix.
+      </li>
+      <li>
+        <span class="param">allow_localhost</span>
+        <span class="param-flags">optional</span>
+        If set, clients can request certificates for `localhost`
+        as one of the requested common names. This is useful
+        for testing and to allow clients on a single host to
+        talk securely.
+        Defaults to true.
+      </li>
+      <li>
+        <span class="param">allowed_base_domain</span>
+        <span class="param-flags">optional</span>
+        If set, clients can request certificates for subdomains
+        directly off of this base domain. _This includes the
+        wildcard subdomain._ For instance, a base_domain of
+        `example.com` allows clients to request certificates for
+        `foo.example.com` and `*.example.com`. To allow further
+        levels of subdomains, enable the `allow_subdomains` option.
+        There is no default.
+      </li>
+      <li>
+        <span class="param">allow_token_displayname</span>
+        <span class="param-flags">optional</span>
+        If set, clients can request certificates matching
+        the value of Display Name from the requesting token.
+        Remember, this stacks with the other CN options,
+        including `allowed_base_domain`. Defaults to `false`.
+      </li>
+      <li>
+        <span class="param">allow_subdomains</span>
+        <span class="param-flags">optional</span>
+        If set, clients can request certificates with CNs that
+        are subdomains of the CNs allowed by the other role
+        options. _This includes wildcard subdomains._ This is
+        redundant when using the `allow_any_name` option.
+        Defaults to `false`.
+      </li>
+      <li>
+        <span class="param">allow_any_name</span>
+        <span class="param-flags">optional</span>
+        If set, clients can request any CN. Useful in some
+        circumstances, but make sure you understand whether it
+        is appropriate for your installation before enabling it.
+        Defaults to `false`.
+      </li>
+      <li>
+        <span class="param">allow_ip_sans</span>
+        <span class="param-flags">optional</span>
+        If set, clients can request IP Subject Alternative
+        Names. Unlike CNs, no authorization checking is
+        performed except to verify that the given values
+        are valid IP addresses. Defaults to `true`.
+      <li>
+        <span class="param">server_flag</span>
+        <span class="param-flags">optional</span>
+        If set, certificates are flagged for server use.
+        Defaults to `true`.
+      </li>
+      <li>
+        <span class="param">client_flag</span>
+        <span class="param-flags">optional</span>
+        If set, certificates are flagged for client use.
+        Defaults to `true`.
+      </li>
+      <li>
+        <span class="param">code_signing_flag</span>
+        <span class="param-flags">optional</span>
+        If set, certificates are flagged for code signing
+        use. Defaults to `false`.
+      </li>
+      <li>
+        <span class="param">key_type</span>
+        <span class="param-flags">optional</span>
+        The type of key to generate for generated private
+        keys. Currently, `rsa` and `ec` are supported.
+        Defaults to `rsa`.
+      </li>
+      <li>
+        <span class="param">key_bits</span>
+        <span class="param-flags">optional</span>
+        The number of bits to use for the generated keys.
+        Defaults to `2048`; this will need to be changed for
+        `ec` keys. See https://golang.org/pkg/crypto/elliptic/#Curve
+        for an overview of allowed bit lengths for `ec`.
+      </li>
+    </ul>
+  </dd>
+
+  <dt>Returns</dt>
+  <dd>
+    A `204` response code.
+  </dd>
+</dl>
+
+#### GET
+
+<dl class="api">
+  <dt>Description</dt>
+  <dd>
+    Queries the role definition.
+  </dd>
+
+  <dt>Method</dt>
+  <dd>GET</dd>
+
+  <dt>URL</dt>
+  <dd>`/pki/roles/<name>`</dd>
+
+  <dt>Parameters</dt>
+  <dd>
+     None
+  </dd>
+
+  <dt>Returns</dt>
+  <dd>
+
+    ```javascript
+    {
+        "data": {
+            "allow_any_name": false,
+            "allow_ip_sans": true,
+            "allow_localhost": true,
+            "allow_subdomains": false,
+            "allow_token_displayname": false,
+            "allowed_base_domain": "example.com",
+            "client_flag": true,
+            "code_signing_flag": false,
+            "key_bits": 2048,
+            "key_type": "rsa",
+            "lease": "6h",
+            "lease_max": "12h",
+            "server_flag": true
+        }
+    }
+    ```
+
+  </dd>
+</dl>
+
+
+#### DELETE
+
+<dl class="api">
+  <dt>Description</dt>
+  <dd>
+    Deletes the role definition. Deleting a role does <b>not</b> revoke
+    certificates previously issued under this role.
+  </dd>
+
+  <dt>Method</dt>
+  <dd>DELETE</dd>
+
+  <dt>URL</dt>
+  <dd>`/pki/roles/<name>`</dd>
+
+  <dt>Parameters</dt>
+  <dd>
+     None
+  </dd>
+
+  <dt>Returns</dt>
+  <dd>
+    A `204` response code.
+  </dd>
+</dl>
diff --git a/website/source/docs/secrets/postgresql/index.html.md b/website/source/docs/secrets/postgresql/index.html.md
new file mode 100644
index 000000000..3d0da282e
--- /dev/null
+++ b/website/source/docs/secrets/postgresql/index.html.md
@@ -0,0 +1,313 @@
+---
+layout: "docs"
+page_title: "Secret Backend: PostgreSQL"
+sidebar_current: "docs-secrets-postgresql"
+description: |-
+  The PostgreSQL secret backend for Vault generates database credentials to access PostgreSQL.
+---
+
+# PostgreSQL Secret Backend
+
+Name: `postgresql`
+
+The PostgreSQL secret backend for Vault generates database credentials
+dynamically based on configured roles. This means that services that need
+to access a database no longer need to hardcode credentials: they can request
+them from Vault, and use Vault's leasing mechanism to more easily roll keys.
+
+Additionally, it introduces a new ability: with every service accessing
+the database with unique credentials, it makes auditing much easier when
+questionable data access is discovered: you can track it down to the specific
+instance of a service based on the SQL username.
+
+Vault makes use both of its own internal revocation system as well as the
+`VALID UNTIL` setting when creating PostgreSQL users to ensure that users
+become invalid within a reasonable time of the lease expiring.
+
+This page will show a quick start for this backend. For detailed documentation
+on every path, use `vault path-help` after mounting the backend.
+
+## Quick Start
+
+The first step to using the PostgreSQL backend is to mount it.
+Unlike the `generic` backend, the `postgresql` backend is not mounted by default.
+
+```text
+$ vault mount postgresql
+Successfully mounted 'postgresql' at 'postgresql'!
+```
+
+Next, Vault must be configured to connect to the PostgreSQL. This is done by
+writing either a PostgreSQL URL or PG connection string:
+
+```text
+$ vault write postgresql/config/connection \
+    value="postgresql://root:vaulttest@vaulttest.ciuvljjni7uo.us-west-1.rds.amazonaws.com:5432/postgres"
+```
+
+In this case, we've configured Vault with the user "root" and password "vaulttest",
+connecting to a PostgreSQL instance in AWS RDS. The "postgres" database name is being used.
+It is important that the Vault user have the `GRANT OPTION` privilege to manage users.
+
+Optionally, we can configure the lease settings for credentials generated
+by Vault. This is done by writing to the `config/lease` key:
+
+```
+$ vault write postgresql/config/lease lease=1h lease_max=24h
+Success! Data written to: postgresql/config/lease
+```
+
+This restricts each credential to being valid or leased for 1 hour
+at a time, with a maximum use period of 24 hours. This forces an
+application to renew their credentials at least hourly, and to recycle
+them once per day.
+
+The next step is to configure a role. A role is a logical name that maps
+to a policy used to generated those credentials. For example, lets create
+a "readonly" role:
+
+```text
+$ vault write postgresql/roles/readonly \
+    sql="CREATE ROLE \"{{name}}\" WITH LOGIN PASSWORD '{{password}}' VALID UNTIL '{{expiration}}';
+    GRANT SELECT ON ALL TABLES IN SCHEMA public TO \"{{name}}\";"
+Success! Data written to: postgresql/roles/readonly
+```
+
+By writing to the `roles/readonly` path we are defining the `readonly` role.
+This role will be created by evaluating the given `sql` statements. By
+default, the `{{name}}`, `{{password}}` and `{{expiration}}` fields will be populated by
+Vault with dynamically generated values. This SQL statement is creating
+the named user, and then granting it `SELECT` or read-only privileges
+to tables in the database. More complex `GRANT` queries can be used to
+customize the privileges of the role. See the [PostgreSQL manual](http://www.postgresql.org/docs/9.4/static/sql-grant.html)
+for more information.
+
+To generate a new set of credentials, we simply read from that role:
+Vault is now configured to create and manage credentials for Postgres!
+
+```text
+$ vault read postgresql/creds/readonly
+Key           	Value
+lease_id      	postgresql/creds/readonly/c888a097-b0e2-26a8-b306-fc7c84b98f07
+lease_duration	3600
+password      	34205e88-0de1-68b7-6267-72d8e32c5d3d
+username      	vault-root-1430162075-7887
+```
+
+By reading from the `creds/readonly` path, Vault has generated a new
+set of credentials using the `readonly` role configuration. Here we
+see the dynamically generated username and password, along with a one
+hour lease.
+
+Using ACLs, it is possible to restrict using the postgresql backend such
+that trusted operators can manage the role definitions, and both
+users and applications are restricted in the credentials they are
+allowed to read.
+
+If you get stuck at any time, simply run `vault path-help postgresql` or with a
+subpath for interactive help output.
+
+## API
+
+### /postgresql/config/connection
+#### POST
+
+<dl class="api">
+  <dt>Description</dt>
+  <dd>
+    Configures the connection string used to communicate with PostgreSQL.
+    This is a root protected endpoint.
+  </dd>
+
+  <dt>Method</dt>
+  <dd>POST</dd>
+
+  <dt>URL</dt>
+  <dd>`/postgresql/config/connection`</dd>
+
+  <dt>Parameters</dt>
+  <dd>
+    <ul>
+      <li>
+        <span class="param">value</span>
+        <span class="param-flags">required</span>
+        The PostgreSQL connection URL or PG style string. e.g. "user=foo host=bar"
+      </li>
+    </ul>
+  </dd>
+
+  <dt>Returns</dt>
+  <dd>
+    A `204` response code.
+  </dd>
+</dl>
+
+### /postgresql/config/lease
+#### POST
+
+<dl class="api">
+  <dt>Description</dt>
+  <dd>
+    Configures the lease settings for generated credentials.
+    If not configured, leases default to 1 hour. This is a root
+    protected endpoint.
+  </dd>
+
+  <dt>Method</dt>
+  <dd>POST</dd>
+
+  <dt>URL</dt>
+  <dd>`/postgresql/config/lease`</dd>
+
+  <dt>Parameters</dt>
+  <dd>
+    <ul>
+      <li>
+        <span class="param">lease</span>
+        <span class="param-flags">required</span>
+        The lease value provided as a string duration
+        with time suffix. Hour is the largest suffix.
+      </li>
+      <li>
+        <span class="param">lease_max</span>
+        <span class="param-flags">required</span>
+        The maximum lease value provided as a string duration
+        with time suffix. Hour is the largest suffix.
+      </li>
+    </ul>
+  </dd>
+
+  <dt>Returns</dt>
+  <dd>
+    A `204` response code.
+  </dd>
+</dl>
+
+### /postgresql/roles/
+#### POST
+
+<dl class="api">
+  <dt>Description</dt>
+  <dd>
+    Creates or updates the role definition.
+  </dd>
+
+  <dt>Method</dt>
+  <dd>POST</dd>
+
+  <dt>URL</dt>
+  <dd>`/postgresql/roles/<name>`</dd>
+
+  <dt>Parameters</dt>
+  <dd>
+    <ul>
+      <li>
+        <span class="param">sql</span>
+        <span class="param-flags">required</span>
+        The SQL statements executed to create and configure the role.
+        Must be semi-colon separated. The '{{name}}', '{{password}}' and
+        '{{expiration}}' values will be substituted.
+      </li>
+    </ul>
+  </dd>
+
+  <dt>Returns</dt>
+  <dd>
+    A `204` response code.
+  </dd>
+</dl>
+
+#### GET
+
+<dl class="api">
+  <dt>Description</dt>
+  <dd>
+    Queries the role definition.
+  </dd>
+
+  <dt>Method</dt>
+  <dd>GET</dd>
+
+  <dt>URL</dt>
+  <dd>`/postgresql/roles/<name>`</dd>
+
+  <dt>Parameters</dt>
+  <dd>
+     None
+  </dd>
+
+  <dt>Returns</dt>
+  <dd>
+
+    ```javascript
+    {
+        "data": {
+            "sql": "CREATE USER..."
+        }
+    }
+    ```
+
+  </dd>
+</dl>
+
+
+#### DELETE
+
+<dl class="api">
+  <dt>Description</dt>
+  <dd>
+    Deletes the role definition.
+  </dd>
+
+  <dt>Method</dt>
+  <dd>DELETE</dd>
+
+  <dt>URL</dt>
+  <dd>`/postgresql/roles/<name>`</dd>
+
+  <dt>Parameters</dt>
+  <dd>
+     None
+  </dd>
+
+  <dt>Returns</dt>
+  <dd>
+    A `204` response code.
+  </dd>
+</dl>
+
+### /postgresql/creds/
+#### GET
+
+<dl class="api">
+  <dt>Description</dt>
+  <dd>
+    Generates a new set of dynamic credentials based on the named role.
+  </dd>
+
+  <dt>Method</dt>
+  <dd>GET</dd>
+
+  <dt>URL</dt>
+  <dd>`/postgresql/creds/<name>`</dd>
+
+  <dt>Parameters</dt>
+  <dd>
+     None
+  </dd>
+
+  <dt>Returns</dt>
+  <dd>
+
+    ```javascript
+    {
+        "data": {
+            "username": "vault-root-1430158508-126",
+            "password": "132ae3ef-5a64-7499-351e-bfe59f3a2a21"
+        }
+    }
+    ```
+
+  </dd>
+</dl>
+
diff --git a/website/source/docs/secrets/ssh/index.html.md b/website/source/docs/secrets/ssh/index.html.md
new file mode 100644
index 000000000..ddae56515
--- /dev/null
+++ b/website/source/docs/secrets/ssh/index.html.md
@@ -0,0 +1,656 @@
+---
+layout: "docs"
+page_title: "Secret Backend: SSH"
+sidebar_current: "docs-secrets-ssh"
+description: |-
+  The SSH secret backend for Vault generates dynamic SSH keys or One-Time-Passwords. 
+---
+
+# SSH Secret Backend
+
+Name: `ssh`
+
+Vault SSH backend generates SSH credentials for remote hosts dynamically. This
+backend increases the security by removing the need to share the private key to
+everyone who needs access to infrastructures. It also solves the problem of
+management and distribution of keys belonging to remote hosts.
+
+This backend supports two types of credential creation: Dynamic and OTP. Both of
+them addresses the problems in different ways.
+
+Read and carefully understand both of them and choose the one which best suits
+your needs.
+
+This page will show a quick start for this backend. For detailed documentation
+on every path, use `vault path-help` after mounting the backend.
+
+----------------------------------------------------
+## I. Dynamic Type
+
+Register the shared secret key (having super user privileges) with Vault and let
+Vault take care of issuing a dynamic secret key every time a client wants to SSH
+into the remote host.
+
+When a Vault authenticated client requests for a dynamic credential, Vault server
+creates a key-pair, uses the previously shared secret key to login to the remote
+host and appends the newly generated public key to `~/.ssh/authorized_keys` file for 
+the desired username. Vault uses an install script (configurable) to achieve this.
+To run this script in super user mode without password prompts, `NOPASSWD` option
+for sudoers should be enabled at all remote hosts.
+
+File: `/etc/sudoers`
+
+```hcl
+%sudo   ALL=(ALL)NOPASSWD: ALL 
+```
+
+The private key returned to the user will be leased and can be renewed if desired.
+Once the key is given to the user, Vault will not know when it gets used or how many
+time it gets used. Therefore, Vault **WILL NOT** and cannot audit the SSH session
+establishments. An alternative is to use OTP type, which audits every SSH request
+(see below).
+
+### Mounting SSH
+
+`ssh` backend is not mounted by default. So, the first step in using the SSH backend
+is to mount it.
+
+```shell
+$ vault mount ssh
+Successfully mounted 'ssh' at 'ssh'!
+```
+
+Next, we must register infrastructures with Vault. This is done by writing the role
+information. The type of credentials created are determined by the `key_type` option.
+To do this, first create a named key and then create a role.
+
+### Registering shared secret key
+
+Create a named key, say `dev_key`, which represents a registered shared private key.
+Remember that this key should be of admin user with super user privileges.
+
+```shell
+$ vault write ssh/keys/dev_key key=@dev_shared_key.pem
+```
+
+### Create a Role
+
+Create a role, say `dynamic_key_role`. All the machines represented by CIDR block
+should be accessible through `dev_key` with root privileges.
+
+```shell
+$ vault write ssh/roles/dynamic_key_role key_type=dynamic key=dev_key admin_user=username default_user=username cidr_list=x.x.x.x/y
+Success! Data written to: ssh/roles/dynamic_key_role
+```
+
+Use the `install_script` option to provide an install script if hosts does not
+resemble typical Linux machine. The default script is compiled into the binary.
+It is straight forward and is shown below. The script takes three arguments which
+are explained in the comments.
+
+```shell
+# This script file installs or uninstalls an RSA public key to/from authoried_keys
+# file in a typical linux machine. This script should be registered with vault
+# server while creating a role for key type 'dynamic'.
+
+# $1: "install" or "uninstall"
+#
+# $2: File name containing public key to be installed. Vault server uses UUID
+# as file name to avoid collisions with public keys generated for requests.
+#
+# $3: Absolute path of the authorized_keys file.
+
+if [ $1 != "install" && $1 != "uninstall" ]; then
+	exit 1
+fi
+
+# If the key being installed is already present in the authorized_keys file, it is
+# removed and the result is stored in a temporary file.
+grep -vFf $2 $3 > temp_$2
+
+# Contents of temporary file will be the contents of authorized_keys file.
+cat temp_$2 | sudo tee $3
+
+if [ $1 == "install" ]; then
+# New public key is appended to authorized_keys file
+cat $2 | sudo tee --append $3
+fi
+
+# Auxiliary files are deleted
+rm -f $2 temp_$2
+```
+
+### Create a credential
+
+Create a dynamic key for an IP that belongs to `dynamic_key_role`.
+
+```shell
+$ vault write ssh/creds/dynamic_key_role ip=x.x.x.x
+Key            	Value
+lease_id       	ssh/creds/dynamic_key_role/8c4d2042-23bc-d6a8-42c2-6ff01cb83cf8
+lease_duration 	600
+lease_renewable	true
+ip             	x.x.x.x
+key            	-----BEGIN RSA PRIVATE KEY-----
+MIIEpAIBAAKCAQEA5V/Y95qfGaUXRPkKNK9jgDHXPD2n5Ein+QTNnLSGrHtJUH7+
+pgs/5Hc4//124P9qHNmjIYQVyvcLreFgSrQCq4K8193hmypBYtsvCgvpc+jEwaGA
+zK0QV7uc1z8KL7FuRAxpHJwB6+nubOzzqM03xsViHRhaWhYVHw2Vl4oputSHE7R9
+ugaTRg67wge4Nyi5RRL0RQcmW15/Vop8B6HpBSmZQy3enjg+32KbOWCMMTAPuF9/
+DgxSgZQaFMjGN4RjDreZI8Vv5zIiFJzZ3KVOWy8piI0PblLnDpU4Q0QSQ9A+Vr7b
+JS22Lbet1Zbapl/n947/r1wGObLCc5Lilu//1QIDAQABAoIBAHWLfdO9sETjHp6h
+BULkkpgScpuTeSN6vGHXvUrOFKn1cCfJPNR4tWBuXI6LJM2+9nEccwXs+4IMwjZ0
+ZfVCdI/SKtZxBXmP2PxBGMUMP7G/mn0kN64sDlD3ezOvQZgZVEmZFpCrvixYsG+v
+qlpZ+HhrlJEWds7tvBsyyfNjwWjVIpm08zBmteFj4zu7OEcmGXEHDoxDXxyVP2BG
+eLU/fM5JA2UEjfCQ1MIZ3rBtPePdz4LRpb+ajklqrUj1OHoiDrXa8EAf0/wDP9re
+c1iH4bn7ZjYK0+IhZ+Pmw6gUftzZNWSC2kOLnZLdN/K7hgh0l0r0K/1eeXt43upB
+WALNuiECgYEA8PM2Ob3XXKALF86PUewne4fCz9iixr/cIpvrEGrh9lyQRO8X5Jxb
+ug38jEql4a574C6TSXfzxURza4P6lnfa0LvymmW0bhxZ5nev9kcAVnLKvpOUArTR
+32k9bKXd6zp8Q9ZyVNwHRxcVs4YgwfJlcx8geC4o6YRiIjvcBQ9RVHkCgYEA87OK
+lZDFBeEY/HVOxAQNXS5fgTd4U4DbwEJLv7SPk02v9oDkGHkpgMs4PcsIpCzsTpJ0
+oXMfLSxZ1lmZiuUvAupKj/7RjJ0XyjSMfm1Zs81epWj+boVfM4amZNHVLIWgddmM
+XzXEZKByvi1gs7qFcjQz2DEbZltWO6dX14O4Fz0CgYEAlWSWyHJWZ02r0xT1c7vS
+NxtTxH7zXftzR9oYgtNiStfVc4gy7kGr9c3aOjnGZAlFMRhvpevDrxnj3lO0OTsS
+5rzBjM1mc6cMboLjDPW01eTSpBroeE0Ym0arGQQ2djSK+5yowsixknhTsj2FbfsW
+v6wa+6jTIQY9ujAXGOQIbzECgYAYuXlw7SwgCZNYYappFqQodQD5giAyEJu66L74
+px/96N7WWoNJvFkqmPOOyV+KEIi0/ATbMGvUUHCY36RFRDU9zXldHJQz+Ogl+qja
+VsvIAyj8DSfrHJrpBlsxVVyUVMZPzo+ARVs0flbF1qK9+Ul6qbMs1uaZvuCD0tmF
+ovZ1XQKBgQDB0s7SDmAMgVjG8UBZgUru9vsDrxERT2BloptnnAjSiarLF5M+qeZO
+7L4NLyVP39Z83eerEonzDAHHbvhPyi6n2YmnYhGjeP+lPZIVqGF9cpZD3q48YHZc
+3ePn2/oLZrXKWOMyMwp2Uj+0SArCW+xMnoNp50sYNVR/JK3BPIdkag==
+-----END RSA PRIVATE KEY-----
+key_type       	dynamic
+port           	22
+username       	username
+```
+
+### Establish an SSH session
+
+Save the key to a file, say `dyn_key.pem`, and then use it to establish an SSH session.
+
+```shell
+$ ssh -i dyn_key.pem username@ip
+username@ip:~$
+```
+
+### Automate it!
+
+Creation of new key, saving it in a file and establishing an SSH session will all be done
+via a single Vault CLI.
+
+```shell
+$ vault ssh -role dynamic_key_role username@ip
+username@ip:~$
+```
+----------------------------------------------------
+## II. One-Time-Password (OTP) Type
+
+Install Vault SSH Agent in remote hosts and let Vault server issue an OTP every time
+a client wants to SSH into remote hosts.
+
+Vault authenticated clients request for a credential from Vault server and get an OTP
+issued. When clients try to establish SSH connection with the remote host, OTP typed
+in at the password prompt will be received by the Vault agent and gets validated
+by the Vault server. Vault server deletes the OTP after validating it once (hence one-time).
+
+Since Vault server is contacted for every successful connection establishment, unlike
+Dynamic type, every login attempt **WILL** be audited.
+
+See [Vault-SSH-Agent](https://github.com/hashicorp/vault-ssh-agent) for details
+on how to configure the agent.
+
+### Mounting SSH
+
+`ssh` backend is not mounted by default and needs to be explicitly mounted. This is
+a common step for both OTP and Dynamic types. 
+
+```shell
+$ vault mount ssh
+Successfully mounted 'ssh' at 'ssh'!
+```
+
+### Creating a Role
+
+Create a role, say `otp_key_role` for key type `otp`. All the machines represented
+by CIDR block should have agent installed in them and have their SSH configuration
+modified to support Vault SSH Agent client authentication.
+
+```shell
+$ vault write ssh/roles/otp_key_role key_type=otp default_user=username cidr_list=x.x.x.x/y,m.m.m.m/n
+Success! Data written to: ssh/roles/otp_key_role
+```
+
+### Create a Credential
+
+Create an OTP credential for an IP that belongs to `otp_key_role`.
+
+```shell
+$ vault write ssh/creds/otp_key_role ip=x.x.x.x
+Key            	Value
+lease_id       	ssh/creds/otp_key_role/73bbf513-9606-4bec-816c-5a2f009765a5
+lease_duration 	600
+lease_renewable	false
+port           	22
+username       	username
+ip             	x.x.x.x
+key            	2f7e25a2-24c9-4b7b-0d35-27d5e5203a5c
+key_type       	otp
+```
+
+### Establish an SSH session
+
+```shell
+$ ssh username@localhost
+Password: <Enter OTP>
+username@ip:~$
+```
+
+### Automate it!
+
+Creation of new OTP and running SSH command can be done via a single CLI.
+
+```shell
+$ vault ssh -role otp_key_role username@x.x.x.x
+OTP for the session is `b4d47e1b-4879-5f4e-ce5c-7988d7986f37`
+[Note: Install `sshpass` to automate typing in OTP]
+Password: <Enter OTP>
+```
+
+OTP will be typed in using `sshpass` if it is installed.
+
+```shell
+$ vault ssh -role otp_key_role username@x.x.x.x
+username@ip:~$ 
+``` 
+----------------------------------------------------
+
+## API
+
+### /ssh/config/lease
+#### POST
+
+<dl class="api">
+  <dt>Description</dt>
+  <dd>
+    Configures the lease settings for generated credentials.
+    This is a root protected endpoint.
+  </dd>
+
+  <dt>Method</dt>
+  <dd>POST</dd>
+
+  <dt>URL</dt>
+  <dd>`/ssh/config/lease`</dd>
+
+  <dt>Parameters</dt>
+  <dd>
+    <ul>
+      <li>
+        <span class="param">lease</span>
+        <span class="param-flags">required</span>
+        (String)
+	The lease value provided as a duration
+        with time suffix. Hour is the largest suffix.
+      </li>
+      <li>
+        <span class="param">lease_max</span>
+        <span class="param-flags">required</span>
+        (String)
+	The maximum lease value provided as a duration
+        with time suffix. Hour is the largest suffix.
+      </li>
+    </ul>
+  </dd>
+
+  <dt>Returns</dt>
+  <dd>
+    A `204` response code.
+  </dd>
+</dl>
+
+### /ssh/keys/
+#### POST
+
+<dl class="api">
+  <dt>Description</dt>
+  <dd>
+    Creates or updates a named key. This is a root protected endpoint.
+  </dd>
+
+  <dt>Method</dt>
+  <dd>POST</dd>
+
+  <dt>URL</dt>
+  <dd>`/ssh/keys/<key name>`</dd>
+
+  <dt>Parameters</dt>
+  <dd>
+    <ul>
+      <li>
+        <span class="param">key</span>
+        <span class="param-flags">required</span>
+        (String)
+	SSH private key with super user privileges in host 
+      </li>
+    </ul>
+  </dd>
+
+  <dt>Returns</dt>
+  <dd>
+    A `204` response code.
+  </dd>
+
+#### GET 
+
+<dl class="api">
+  <dt>Description</dt>
+  <dd>
+    Queries a named key. This is a root protected endpoint.
+  </dd>
+
+  <dt>Method</dt>
+  <dd>GET</dd>
+
+  <dt>URL</dt>
+  <dd>`/ssh/keys/<key name>`</dd>
+
+  <dt>Parameters</dt>
+  <dd>None</dd>
+  
+  <dt>Returns</dt>
+  <dd>
+
+```javascript
+{
+		"key": "-----BEGIN RSA PRIVATE KEY-----\nMIIEogIBAAKCAQEAvYvoRcWRxqOim5VZnuM6wHCbLUeiND0yaM1tvOl+Fsrz55DG\nA0OZp4RGAu1Fgr46E1mzxFz1+zY4UbcEExg+u21fpa8YH8sytSWW1FyuD8ICib0A\n/l8slmDMw4BkkGOtSlEqgscpkpv/TWZD1NxJWkPcULk8z6c7TOETn2/H9mL+v2RE\nmbE6NDEwJKfD3MvlpIqCP7idR+86rNBAODjGOGgyUbtFLT+K01XmDRALkV3V/nh+\nGltyjL4c6RU4zG2iRyV5RHlJtkml+UzUMkzr4IQnkCC32CC/wmtoo/IsAprpcHVe\nnkBn3eFQ7uND70p5n6GhN/KOh2j519JFHJyokwIDAQABAoIBAHX7VOvBC3kCN9/x\n+aPdup84OE7Z7MvpX6w+WlUhXVugnmsAAVDczhKoUc/WktLLx2huCGhsmKvyVuH+\nMioUiE+vx75gm3qGx5xbtmOfALVMRLopjCnJYf6EaFA0ZeQ+NwowNW7Lu0PHmAU8\nZ3JiX8IwxTz14DU82buDyewO7v+cEr97AnERe3PUcSTDoUXNaoNxjNpEJkKREY6h\n4hAY676RT/GsRcQ8tqe/rnCqPHNd7JGqL+207FK4tJw7daoBjQyijWuB7K5chSal\noPInylM6b13ASXuOAOT/2uSUBWmFVCZPDCmnZxy2SdnJGbsJAMl7Ma3MUlaGvVI+\nTfh1aQkCgYEA4JlNOabTb3z42wz6mz+Nz3JRwbawD+PJXOk5JsSnV7DtPtfgkK9y\n6FTQdhnozGWShAvJvc+C4QAihs9AlHXoaBY5bEU7R/8UK/pSqwzam+MmxmhVDV7G\nIMQPV0FteoXTaJSikhZ88mETTegI2mik+zleBpVxvfdhE5TR+lq8Br0CgYEA2AwJ\nCUD5CYUSj09PluR0HHqamWOrJkKPFPwa+5eiTTCzfBBxImYZh7nXnWuoviXC0sg2\nAuvCW+uZ48ygv/D8gcz3j1JfbErKZJuV+TotK9rRtNIF5Ub7qysP7UjyI7zCssVM\nkuDd9LfRXaB/qGAHNkcDA8NxmHW3gpln4CFdSY8CgYANs4xwfercHEWaJ1qKagAe\nrZyrMpffAEhicJ/Z65lB0jtG4CiE6w8ZeUMWUVJQVcnwYD+4YpZbX4S7sJ0B8Ydy\nAhkSr86D/92dKTIt2STk6aCN7gNyQ1vW198PtaAWH1/cO2UHgHOy3ZUt5X/Uwxl9\ncex4flln+1Viumts2GgsCQKBgCJH7psgSyPekK5auFdKEr5+Gc/jB8I/Z3K9+g4X\n5nH3G1PBTCJYLw7hRzw8W/8oALzvddqKzEFHphiGXK94Lqjt/A4q1OdbCrhiE68D\nMy21P/dAKB1UYRSs9Y8CNyHCjuZM9jSMJ8vv6vG/SOJPsnVDWVAckAbQDvlTHC9t\nO98zAoGAcbW6uFDkrv0XMCpB9Su3KaNXOR0wzag+WIFQRXCcoTvxVi9iYfUReQPi\noOyBJU/HMVvBfv4g+OVFLVgSwwm6owwsouZ0+D/LasbuHqYyqYqdyPJQYzWA2Y+F\n+B6f4RoPdSXj24JHPg/ioRxjaj094UXJxua2yfkcecGNEuBQHSs=\n-----END RSA PRIVATE KEY-----\n"
+}
+```
+  </dd>
+
+
+#### DELETE 
+
+<dl class="api">
+  <dt>Description</dt>
+  <dd>
+    Deletes a named key. This is a root protected endpoint.
+  </dd>
+
+  <dt>Method</dt>
+  <dd>DELETE</dd>
+
+  <dt>URL</dt>
+  <dd>`/ssh/keys/<key name>`</dd>
+
+  <dt>Parameters</dt>
+  <dd>None</dd>
+
+  <dt>Returns</dt>
+  <dd>
+    A `204` response code.
+  </dd>
+
+### /ssh/roles/
+#### POST
+
+<dl class="api">
+  <dt>Description</dt>
+  <dd>
+    Creates or updates a named role.
+  </dd>
+
+  <dt>Method</dt>
+  <dd>POST</dd>
+
+  <dt>URL</dt>
+  <dd>`/ssh/roles/<role name>`</dd>
+
+  <dt>Parameters</dt>
+  <dd>
+    <ul>
+      <li>
+        <span class="param">key</span>
+        <span class="param-flags">required for Dynamic type, NA for OTP type</span>
+	(String)
+        Name of the registered key in Vault. Before creating the role, use
+        the `keys/` endpoint to create a named key.
+      </li>
+      <li>
+        <span class="param">admin_user</span>
+        <span class="param-flags">required for Dynamic type, NA for OTP type</span>
+	(String)
+	Admin user at remote host. The shared key being registered should be
+	for this user and should have root privileges. Everytime a dynamic 
+	credential is being generated for other users, Vault uses this admin
+	username to login to remote host and install the generated credential
+	for the other user.
+      </li>
+      <li>
+        <span class="param">default_user</span>
+        <span class="param-flags">required for both types</span>
+	(String)
+	Default username for which a credential will be generated.
+	When the endpoint 'creds/' is used without a username, this
+	value will be used as default username.
+      </li>
+      <li>
+        <span class="param">cidr_list</span>
+        <span class="param-flags">required for both types</span>
+	(String)
+	Comma separated list of CIDR blocks for which the role is applicable for.
+	CIDR blocks can belong to more than one role.
+      </li>
+      <li>
+        <span class="param">port</span>
+        <span class="param-flags">optional for both types</span>
+	(Integer)
+	Port number for SSH connection. Default is '22'. Port number does not
+	play any role in creation of OTP. For 'otp' type, this is just a way
+	to inform client about the port number to use. Port number will be
+	returned to client by Vault server along with OTP.
+      </li>
+      <li>
+        <span class="param">key_type</span>
+        <span class="param-flags">required for both types</span>
+	(String)
+	Type of key used to login to hosts. It can be either `otp` or `dynamic`.
+	`otp` type requires agent to be installed in remote hosts.
+      </li>
+      <li>
+        <span class="param">key_bits</span>
+        <span class="param-flags">optional for Dynamic type, NA for OTP type</span>
+	(Integer)
+	Length of the RSA dynamic key in bits. It is 1024 by default or it can be 2048.
+      </li>
+      <li>
+        <span class="param">install_script</span>
+        <span class="param-flags">optional for Dynamic type, NA for OTP type</span>
+	(String)
+	Script used to install and uninstall public keys in the target machine.
+	The inbuilt default install script will be for Linux hosts.
+      </li>
+      <li>
+        <span class="param">allowed_users</span>
+        <span class="param-flags">optional for both types</span>
+	(String)
+	If this option is not specified, client can request for a credential for
+	any valid user at the remote host, including the admin user. If only certain
+	usernames are to be allowed, then this list enforces it. If this field is
+	set, then credentials can only be created for default_user and usernames
+	present in this list.
+      </li>
+    </ul>
+  </dd>
+
+  <dt>Returns</dt>
+  <dd>
+    A `204` response code.
+  </dd>
+
+#### GET 
+
+<dl class="api">
+  <dt>Description</dt>
+  <dd>
+    Queries a named role.
+  </dd>
+
+  <dt>Method</dt>
+  <dd>GET</dd>
+
+  <dt>URL</dt>
+  <dd>`/ssh/roles/<role name>`</dd>
+
+  <dt>Parameters</dt>
+  <dd>None</dd>
+  
+  <dt>Returns</dt>
+  <dd>For dynamic role:
+
+```json
+{
+		"admin_user": "username",
+		"cidr_list": "x.x.x.x/y",
+		"default_user": "username",
+		"key": "<key name>",
+		"key_type": "dynamic",
+		"port": 22
+}
+```
+  </dd>
+
+  <dd>For OTP role:
+
+```json
+{
+		"cidr_list": "x.x.x.x/y",
+		"default_user": "username",
+		"key_type": "otp",
+		"port": 22
+}
+```
+  </dd>
+
+
+#### DELETE 
+
+<dl class="api">
+  <dt>Description</dt>
+  <dd>
+    Deletes a named role.
+  </dd>
+
+  <dt>Method</dt>
+  <dd>DELETE</dd>
+
+  <dt>URL</dt>
+  <dd>`/ssh/roles/<role name>`</dd>
+
+  <dt>Parameters</dt>
+  <dd>None</dd>
+
+  <dt>Returns</dt>
+  <dd>
+    A `204` response code.
+  </dd>
+### /ssh/creds/
+#### POST
+
+<dl class="api">
+  <dt>Description</dt>
+  <dd>
+    Creates a credential for a specific username and IP under the given role.
+  </dd>
+
+  <dt>Method</dt>
+  <dd>POST</dd>
+
+  <dt>URL</dt>
+  <dd>`/ssh/creds/<role name>`</dd>
+
+  <dt>Parameters</dt>
+  <dd>
+    <ul>
+      <li>
+        <span class="param">username</span>
+        <span class="param-flags">optional</span>
+	(String)
+        Username in remote host.
+      </li>
+      <li>
+        <span class="param">ip</span>
+        <span class="param-flags">required</span>
+	(String)
+        IP of the remote host.
+      </li>
+    </ul>
+  </dd>
+  
+  <dt>Returns</dt>
+  <dd>
+    A `204` response code.
+  </dd>
+
+### /ssh/lookup
+#### POST
+
+<dl class="api">
+  <dt>Description</dt>
+  <dd>
+    Lists all the roles given IP is associated with.
+  </dd>
+
+  <dt>Method</dt>
+  <dd>POST</dd>
+
+  <dt>URL</dt>
+  <dd>`/ssh/lookup`</dd>
+
+  <dt>Parameters</dt>
+  <dd>
+    <ul>
+      <li>
+        <span class="param">ip</span>
+        <span class="param-flags">required</span>
+	(String)
+        IP of the remote host.
+      </li>
+    </ul>
+  </dd>
+
+  <dt>Returns</dt>
+  <dd>
+    A `204` response code.
+  </dd>
+
+### /ssh/verify
+#### POST
+
+<dl class="api">
+  <dt>Description</dt>
+  <dd>
+    Verifies if the given OTP is valid. This is an unauthenticated endpoint.
+  </dd>
+
+  <dt>Method</dt>
+  <dd>POST</dd>
+
+  <dt>URL</dt>
+  <dd>`/ssh/verify`</dd>
+
+  <dt>Parameters</dt>
+  <dd>
+    <ul>
+      <li>
+        <span class="param">otp</span>
+        <span class="param-flags">required</span>
+	(String)
+        One-Time-Key that needs to be validated.
+      </li>
+    </ul>
+  </dd>
+
+  <dt>Returns</dt>
+  <dd>
+    A `204` response code.
+  </dd>
+
diff --git a/website/source/docs/secrets/transit/index.html.md b/website/source/docs/secrets/transit/index.html.md
new file mode 100644
index 000000000..8063ac9e3
--- /dev/null
+++ b/website/source/docs/secrets/transit/index.html.md
@@ -0,0 +1,342 @@
+---
+layout: "docs"
+page_title: "Secret Backend: Transit"
+sidebar_current: "docs-secrets-transit"
+description: |-
+  The transit secret backend for Vault encrypts/decrypts data in-transit. It doesn't store any secrets.
+---
+
+# Transit Secret Backend
+
+Name: `transit`
+
+The transit secret backend is used to encrypt/data in-transit. Vault doesn't
+store the data sent to the backend. It can also be viewed as "encryption as
+a service."
+
+The primary use case for the transit backend is to encrypt data from
+applications while still storing that encrypted data in some primary data
+store. This relieves the burden of proper encryption/decryption from
+application developers and pushes the burden onto the operators of Vault.
+Operators of Vault generally include the security team at an organization,
+which means they can ensure that data is encrypted/decrypted properly.
+
+As of Vault 0.2, the transit backend also supports doing key derivation. This
+allows data to be encrypted within a context such that the same context must be
+used for decryption. This can be used to enable per transaction unique keys which
+further increase the security of data at rest.
+
+Additionally, since encrypt/decrypt operations must enter the audit log,
+any decryption event is recorded.
+
+This page will show a quick start for this backend. For detailed documentation
+on every path, use `vault path-help` after mounting the backend.
+
+## Quick Start
+
+The first step to using the transit backend is to mount it. Unlike the `generic`
+backend, the `transit` backend is not mounted by default.
+
+```
+$ vault mount transit
+Successfully mounted 'transit' at 'transit'!
+```
+
+The next step is to create a named encryption key. A named key is used so that
+many different applications can use the transit backend with independent keys.
+This is done by doing a write against the backend:
+
+```
+$ vault write -f transit/keys/foo
+Success! Data written to: transit/keys/foo
+```
+
+This will create the "foo" named key in the transit backend. We can inspect
+the settings of the "foo" key by reading it:
+
+```
+$ vault read transit/keys/foo
+Key        	Value
+name        foo
+cipher_mode aes-gcm
+derived     false
+````
+
+We can read from the `raw/` endpoint to see the encryption key itself:
+
+```
+$ vault read transit/raw/foo
+Key        	Value
+name       	foo
+cipher_mode	aes-gcm
+key        	PhKFTALCmhAhVQfMBAH4+UwJ6J2gybapUH9BsrtIgR8=
+derived     false
+````
+
+Here we can see that the randomly generated encryption key being used, as
+well as the AES-GCM cipher mode. We don't need to know any of this to use
+the key however.
+
+Now, if we wanted to encrypt a piece of plain text, we use the encrypt
+endpoint using our named key:
+
+```
+$ echo -n "the quick brown fox" | base64 | vault write transit/encrypt/foo plaintext=-
+Key       	Value
+ciphertext	vault:v0:czEwyKqGZY/limnuzDCUUe5AK0tbBObWqeZgFqxCuIqq7A84SeiOq3sKD0Y/KUvv
+```
+
+The encryption endpoint expects the plaintext to be provided as a base64 encoded
+strings, so we must first convert it. Vault does not store the plaintext or the
+ciphertext, but only handles it _in transit_ for processing. The application
+is free to store the ciphertext in a database or file at rest.
+
+To decrypt, we simply use the decrypt endpoint using the same named key:
+
+```
+$ vault write transit/decrypt/foo ciphertext=vault:v0:czEwyKqGZY/limnuzDCUUe5AK0tbBObWqeZgFqxCuIqq7A84SeiOq3sKD0Y/KUvv
+Key      	Value
+plaintext	dGhlIHF1aWNrIGJyb3duIGZveAo=
+
+$ echo "dGhlIHF1aWNrIGJyb3duIGZveAo=" | base64 -D
+the quick brown fox
+```
+
+Using ACLs, it is possible to restrict using the transit backend such
+that trusted operators can manage the named keys, and applications can
+only encrypt or decrypt using the named keys they need access to.
+
+## API
+
+### /transit/keys/
+#### POST
+
+<dl class="api">
+  <dt>Description</dt>
+  <dd>
+    Creates a new named encryption key. This is a root protected endpoint.
+  </dd>
+
+  <dt>Method</dt>
+  <dd>POST</dd>
+
+  <dt>URL</dt>
+  <dd>`/transit/keys/<name>`</dd>
+
+  <dt>Parameters</dt>
+  <dd>
+    <ul>
+      <li>
+        <span class="param">derived</span>
+        <span class="param-flags">optional</span>
+        Boolean flag indicating if key derivation MUST be used.
+        If enabled, all encrypt/decrypt requests to this named key
+        must provide a context which is used for key derivation.
+        Defaults to false.
+      </li>
+    </ul>
+  </dd>
+
+  <dt>Returns</dt>
+  <dd>
+    A `204` response code.
+  </dd>
+</dl>
+
+#### GET
+
+<dl class="api">
+  <dt>Description</dt>
+  <dd>
+    Returns information about a named encryption key.
+    This is a root protected endpoint.
+  </dd>
+
+  <dt>Method</dt>
+  <dd>GET</dd>
+
+  <dt>URL</dt>
+  <dd>`/transit/keys/<name>`</dd>
+
+  <dt>Parameters</dt>
+  <dd>
+    None
+  </dd>
+
+  <dt>Returns</dt>
+  <dd>
+
+    ```javascript
+    {
+      "data": {
+          "name":        "foo",
+          "cipher_mode": "aes-gcm",
+          "derived":     "true",
+          "kdf_mode":    "hmac-sha256-counter",
+      }
+    }
+    ```
+
+  </dd>
+</dl>
+
+#### DELETE
+
+<dl class="api">
+  <dt>Description</dt>
+  <dd>
+    Deletes a named encryption key. This is a root protected endpoint.
+    All data encrypted with the named key will no longer be decryptable.
+  </dd>
+
+  <dt>Method</dt>
+  <dd>DELETE</dd>
+
+  <dt>URL</dt>
+  <dd>`/transit/keys/<name>`</dd>
+
+  <dt>Parameters</dt>
+  <dd>
+    None
+  </dd>
+
+  <dt>Returns</dt>
+  <dd>
+    A `204` response code.
+  </dd>
+</dl>
+
+### /transit/encrypt/
+#### POST
+
+<dl class="api">
+  <dt>Description</dt>
+  <dd>
+    Encrypts the provided plaintext using the named key. If the named key
+    does not already exist, it will be automatically generated for the given
+    name with the default parameters.
+  </dd>
+
+  <dt>Method</dt>
+  <dd>POST</dd>
+
+  <dt>URL</dt>
+  <dd>`/transit/encrypt/<name>`</dd>
+
+  <dt>Parameters</dt>
+  <dd>
+    <ul>
+      <li>
+        <span class="param">plaintext</span>
+        <span class="param-flags">required</span>
+        The plaintext to encrypt, provided as base64 encoded.
+      </li>
+      <li>
+        <span class="param">context</span>
+        <span class="param-flags">optional</span>
+        The key derivation context, provided as base64 encoded.
+        Must be provided if the derivation enabled.
+      </li>
+    </ul>
+  </dd>
+
+  <dt>Returns</dt>
+  <dd>
+
+    ```javascript
+    {
+        "data": {
+            "ciphertext": "vault:v0:abcdefgh"
+        }
+    }
+    ```
+
+  </dd>
+</dl>
+
+### /transit/decrypt/
+#### POST
+
+<dl class="api">
+  <dt>Description</dt>
+  <dd>
+    Decrypts the provided ciphertext using the named key.
+  </dd>
+
+  <dt>Method</dt>
+  <dd>POST</dd>
+
+  <dt>URL</dt>
+  <dd>`/transit/decrypt/<name>`</dd>
+
+  <dt>Parameters</dt>
+  <dd>
+    <ul>
+      <li>
+        <span class="param">ciphertext</span>
+        <span class="param-flags">required</span>
+        The ciphertext to decrypt, provided as returned by encrypt.
+      </li>
+      <li>
+        <span class="param">context</span>
+        <span class="param-flags">optional</span>
+        The key derivation context, provided as base64 encoded.
+        Must be provided if the derivation enabled.
+      </li>
+    </ul>
+  </dd>
+
+  <dt>Returns</dt>
+  <dd>
+
+    ```javascript
+    {
+        "data": {
+            "plaintext": "dGhlIHF1aWNrIGJyb3duIGZveAo="
+        }
+    }
+    ```
+
+  </dd>
+</dl>
+
+### /transit/raw/
+#### GET
+
+<dl class="api">
+  <dt>Description</dt>
+  <dd>
+    Returns raw information about a named encryption key,
+    Including the underlying encryption key. This is a root protected endpoint.
+  </dd>
+
+  <dt>Method</dt>
+  <dd>GET</dd>
+
+  <dt>URL</dt>
+  <dd>`/transit/raw/<name>`</dd>
+
+  <dt>Parameters</dt>
+  <dd>
+    None
+  </dd>
+
+  <dt>Returns</dt>
+  <dd>
+
+    ```javascript
+    {
+      "data": {
+          "name":        "foo",
+          "cipher_mode": "aes-gcm",
+          "key":         "PhKFTALCmhAhVQfMBAH4+UwJ6J2gybapUH9BsrtIgR8="
+          "derived":     "true",
+          "kdf_mode":    "hmac-sha256-counter",
+      }
+    }
+    ```
+
+  </dd>
+</dl>
+
+
diff --git a/website/source/downloads.html.erb b/website/source/downloads.html.erb
new file mode 100644
index 000000000..c6d763b38
--- /dev/null
+++ b/website/source/downloads.html.erb
@@ -0,0 +1,48 @@
+---
+layout: "downloads"
+page_title: "Download Vault"
+sidebar_current: "downloads-vault"
+description: |-
+  Download Vault
+---
+
+<h1>Download Vault</h1>
+
+<section class="downloads">
+	<div class="description row">
+		<div class="col-md-12">
+			<p>
+			Below are all available downloads for the latest version of Vault
+			(<%= latest_version %>). Please download the proper package for your
+			operating system and architecture. You can find SHA256 checksums
+			for packages <a href="https://dl.bintray.com/mitchellh/vault/vault_<%= latest_version %>_SHA256SUMS?direct">here</a>. You can verify the SHA256 checksums using <a href="https://hashicorp.com/security.html">our PGP public key</a> and the <a href="https://dl.bintray.com/mitchellh/vault/vault_<%= latest_version %>_SHA256SUMS.sig?direct">SHA256SUMs signature file</a>.
+			</p>
+		</div>
+	</div>
+	<% product_versions.each do |os, versions| %>
+		<div class="row">
+		<div class="col-md-12 download">
+			<div class="icon pull-left"><%= system_icon(os) %>
+		</div>
+			<div class="details">
+				<h2 class="os-name"><%= os %></h2>
+				<ul>
+					<% versions.each do |url| %>
+						<li><a href="<%= url %>"><%= arch_for_filename(url) %></a></li>
+					<% end %>
+				</ul>
+				<div class="clearfix">
+				</div>
+			</div>
+		</div>
+	</div>
+<% end %>
+
+	<div class="row">
+		<div class="col-md-12 poweredby">
+			<a href='http://www.bintray.com'>
+				<img src='https://www.bintray.com/docs/images/poweredByBintray_ColorTransparent.png'>
+			</a>
+		</div>
+	</div>
+</section>
diff --git a/website/source/favicon.png b/website/source/favicon.png
new file mode 100644
index 000000000..130634732
Binary files /dev/null and b/website/source/favicon.png differ
diff --git a/website/source/index.html.erb b/website/source/index.html.erb
new file mode 100644
index 000000000..3d0249134
--- /dev/null
+++ b/website/source/index.html.erb
@@ -0,0 +1,128 @@
+
+
+<div id="hero">
+	<div class="container">
+		<div class="row">
+			<div class="col-md-12">
+				<div id="hero-graphic">
+					<div id="cubes">
+						<div class="cube">
+						  <span class="face top"></span>
+						  <span class="face left"></span>
+						  <span class="face right"></span>
+						</div>
+					</div>
+					<div id="hero-logotype"></div>
+				</div>
+				<div id="hero-text">
+					<h1>Applications on a global fleet.</h1>
+					<h3>As simple as a Single Machine.</h3>
+					<div id="hero-btns">
+						<a class="h-btn light lrg has-caret intro" href="/intro">Learn More<span class="h-caret"></span></a>
+						<a class="h-btn green lrg has-caret has-border try" href="">Try Nomad<span class="h-caret"></span></a>
+					</div>
+				</div>
+			</div>
+		</div>
+	</div>
+</div>
+
+<div id="subhero-banner" class="banner gray-banner">
+	<div class="container">
+		<div class="row">
+			<div class="col col-md-12">
+				<p>Read about how Hashicorp’s scheduler, Nomad, works on our blog</p>
+				<a class="blog-btn h-btn gray sml fill has-caret" href="/intro">Blog<span class="h-caret"></span></a>
+			</div>
+		</div>
+	</div>
+</div>
+
+<div id="content">
+	<div class="container">
+		<div class="row">
+			<div class=" col-md-12">
+				<h2 class="feature-section-title">Overview</h2>
+
+				<div id="deploy" class="feature">
+					<div class="feature-header">
+						<h3>Deploy to any cloud</h3>
+						<p>Deploy Applications and Docker containers across datacenters to any cloud</p>
+					</div>
+					<div class="feature-footer">
+						<p>Phasellus quis arcu nec turpis aliquet malesuada. Pellentesque auctor fermentum cursus.</p>
+						<span class="docker-outline-logo"></span>
+					</div>
+				</div> <!-- .feature -->
+
+				<div id="partners" class="feature">
+					<div class="feature-header right clearfix">
+						<div class="row">
+							<h3 class="">Use your cloud provider with Docker</h3>
+						</div>
+						<div class="row">
+							<p>Lorem ipsum dolor sit amet, consectetur adipiscing elit. Quisque hendrerit nulla ut orci ultricies viverra.</p>
+						</div>
+					</div>
+					<div class="partner-logos">
+						<div class="row">
+							<div class="col-md-2 docker-wrap">
+								<span class="partner-logo docker-logo"></span>
+							</div>
+							<div class="col-md-10 cloud-wrap clearfix">
+								<span class="partner-logo aws-logo"></span>
+								<span class="partner-logo google-logo"></span>
+								<span class="partner-logo microsoft-logo"></span>
+								<span class="partner-logo engineyard-logo"></span>
+							</div>
+						</div>
+					</div>
+				</div> <!-- .feature -->
+
+				<div id="maintain" class="feature">
+					<div class="feature-header">
+						<h3>Manage constraints and workload requirements</h3>
+						<p>Lorem ipsum dolor sit amet, consectetur adipiscing elit. Quisque hendrerit nulla ut orci ultricies viverra.</p>
+					</div>
+					<div class="feature-graphic"></div>
+				</div> <!-- .feature -->
+
+				<div id="healing" class="feature">
+					<div class="feature-header right clearfix">
+						<div class="row">
+							<div class="col-xs-12">
+								<h3>Automatic machine failure healing and blue/green deployments</h3>
+							</div>
+						</div>
+						<div class="row">
+							<div class="col-xs-12">
+								<p>Lorem ipsum dolor sit amet, consectetur adipiscing elit. Quisque hendrerit nulla ut orci ultricies viverra.</p>
+							</div>
+						</div>
+					</div>
+					<div class="feature-graphic"></div>
+				</div> <!-- .feature -->
+
+				<div id="density" class="feature">
+					<div class="feature-header">
+						<h3>Increase density and reduce cost</h3>
+						<p>Lorem ipsum dolor sit amet, consectetur adipiscing elit. Quisque hendrerit nulla ut orci ultricies viverra.</p>
+					</div>
+					<div class="feature-graphic"></div>
+				</div> <!-- .feature -->
+
+			</div> <!-- .col -->
+		</div> <!-- .row -->
+	</div> <!-- /container -->
+</div> <!-- #content -->
+
+<div id="cta-banner" class="banner green-banner">
+	<div class="container">
+		<div class="row">
+			<div class="col col-md-12">
+				<p>Completely free and open source.</p>
+				<a class="blog-btn h-btn green lrg fill has-caret" href="/intro">Try Nomad<span class="h-caret"></span></a>
+			</div>
+		</div>
+	</div>
+</div>
diff --git a/website/source/intro/examples/aws.html.markdown b/website/source/intro/examples/aws.html.markdown
new file mode 100644
index 000000000..fb9ec7d54
--- /dev/null
+++ b/website/source/intro/examples/aws.html.markdown
@@ -0,0 +1,28 @@
+---
+layout: "intro"
+page_title: "Basic Two-Tier AWS Architecture"
+sidebar_current: "examples-aws"
+description: |-
+  This provides a template for running a simple two-tier architecture on Amazon Web services. The premise is that you have stateless app servers running behind an ELB serving traffic.
+---
+
+# Basic Two-Tier AWS Architecture
+
+[**Example Contents**](https://github.com/hashicorp/vault/tree/master/examples/aws-two-tier)
+
+This provides a template for running a simple two-tier architecture on Amazon
+Web services. The premise is that you have stateless app servers running behind
+an ELB serving traffic.
+
+To simplify the example, this intentionally ignores deploying and
+getting your application onto the servers. However, you could do so either via
+[provisioners](/docs/provisioners/index.html) and a configuration
+management tool, or by pre-baking configured AMIs with
+[Packer](https://www.packer.io).
+
+After you run `vault apply` on this configuration, it will
+automatically output the DNS address of the ELB. After your instance
+registers, this should respond with the default nginx web page.
+
+As with all examples, just copy and paste the example and run
+`vault apply` to see it work.
diff --git a/website/source/intro/getting-started/acl.html.md b/website/source/intro/getting-started/acl.html.md
new file mode 100644
index 000000000..446affbe8
--- /dev/null
+++ b/website/source/intro/getting-started/acl.html.md
@@ -0,0 +1,135 @@
+---
+layout: "intro"
+page_title: "Access Control Policies"
+sidebar_current: "gettingstarted-acl"
+description: |-
+  Access control policies in Vault control what a user can access.
+---
+
+# Access Control Policies (ACLs)
+
+Access control policies in Vault control what a user can access. In
+the last section, we learned about _authentication_. This section is
+about _authorization_.
+
+Whereas for authentication Vault has multiple options or backends that
+can be enabled and used, the authorization or policies of Vault are always
+the same format. All authentication backends must map identities back to
+the core policies that are configured with Vault.
+
+When initializing Vault, there is always one special policy created
+that can't be removed: the "root" policy. This policy is a special policy
+that gives superuser access to everything in Vault. An identity mapped to
+the root policy can do anything.
+
+## Policy Format
+
+Policies in Vault are formatted with
+[HCL](https://github.com/hashicorp/hcl). HCL is a human-readable configuration
+format that is also JSON-compatible, so you can use JSON as well. An example
+policy is shown below:
+
+```javascript
+path "secret/*" {
+  policy = "write"
+}
+
+path "secret/foo" {
+  policy = "read"
+}
+```
+
+The policy format uses a prefix matching system on the API path
+to determine access control. The most specific defined policy is used,
+either an exact match or the longest-prefix glob match. Since everything
+in Vault must be accessed via the API, this gives strict control over every
+aspect of Vault, including mounting backends, authenticating, as well as secret access.
+
+In the policy above, a user could write any secret to `secret/`, except
+to `secret/foo`, where only read access is allowed. Policies default to
+deny, so any access to an unspecified path is not allowed. The policy
+language changed slightly in Vault 0.2, [see this page for details](/docs/concepts/policies.html).
+
+Save the above policy as `acl.hcl`.
+
+## Writing the Policy
+
+To write a policy, use the `vault policy-write` command:
+
+```
+$ vault policy-write secret acl.hcl
+Policy 'secret' written.
+```
+
+You can see the policies that are available with `vault policies`, and you
+can see the contents of a policy with `vault policies <name>`. Only users with
+root access can do this.
+
+## Testing the Policy
+
+To use the policy, let's create a token and assign it to that policy.
+Make sure to save your root token somewhere so you can authenticate
+back to a root user later.
+
+```
+$ vault token-create -policy="secret"
+d97ef000-48cf-45d9-1907-3ea6ce298a29
+
+$ vault auth d97ef000-48cf-45d9-1907-3ea6ce298a29
+Successfully authenticated! The policies that are associated
+with this token are listed below:
+
+secret
+```
+
+You can now verify that you can write data to `secret/`, but only
+read from `secret/foo`:
+
+```
+$ vault write secret/bar value=yes
+Success! Data written to: secret/bar
+
+$ vault write secret/foo value=yes
+Error writing data to secret/foo: Error making API request.
+
+URL: PUT http://127.0.0.1:8200/v1/secret/foo
+Code: 400. Errors:
+
+* permission denied
+```
+
+You also don't have access to `sys` according to the policy, so commands
+such as `vault mounts` will not work either.
+
+## Mapping Policies to Auth Backends
+
+Vault is the single policy authority, unlike auth where you can mount
+multiple backends. Any mounted auth backend must map identities to these
+core policies.
+
+Use the `vault path-help` system with your auth backend to determine how the
+mapping is done, since it is specific to each backend. For example,
+with GitHub, it is done by team using the `map/teams/<team>` path:
+
+```
+$ vault write auth/github/map/teams/default value=secret
+Success! Data written to: auth/github/map/teams/default
+```
+
+For GitHub, the "default" team is the default policy set that everyone
+is assigned to no matter what team they're on.
+
+Other auth backends use alternate, but likely similar mechanisms for
+mapping policies to identity.
+
+## Next
+
+Policies are an important part of Vault. While using the root token
+is easiest to get up and running, you'll want to restrict access to
+Vault very quickly, and the policy system is the way to do this.
+
+The syntax and function of policies is easy to understand and work
+with, and because auth backends all must map to the central policy system,
+you only have to learn this policy system.
+
+Next, we'll cover how to [deploy Vault](/intro/getting-started/deploy.html).
diff --git a/website/source/intro/getting-started/apis.html.md b/website/source/intro/getting-started/apis.html.md
new file mode 100644
index 000000000..753b96517
--- /dev/null
+++ b/website/source/intro/getting-started/apis.html.md
@@ -0,0 +1,208 @@
+---
+layout: "intro"
+page_title: "Using the HTTP APIs with Authentication"
+sidebar_current: "gettingstarted-apis"
+description: |-
+  Using the HTTP APIs for authentication and secret access.
+---
+
+# Using the HTTP APIs with Authentication
+All of Vault's capabilities are accessible via the HTTP API in addition to the CLI. In fact, most calls from the CLI actually invoke the HTTP API. In some cases, Vault features are not available via the CLI and can only be accessed via the HTTP API.
+
+Once you have started the Vault server, you can use `curl` or any other http client to make API calls. For example, if you started the Vault server in [development mode](/docs/concepts/dev-server.html), you could validate the initialization status like this:
+
+```
+$ curl http://127.0.0.1:8200/v1/sys/init
+```
+
+This will return a JSON response:
+
+```javascript
+{"initialized":true}
+```
+
+## Accessing Secrets via the REST APIs
+Machines that need access to information stored in Vault will most likely access Vault via its REST API. For example, if a machine were using [app-id](/docs/auth/app-id.html) for authentication, the application would first authenticate to Vault which would return a Vault API token. The application would use that token for future communication with Vault.
+
+For the purpose of this guide, we will use the following configuration which disables TLS and uses a file-based backend. You should never disable TLS in production, but it is okay for the purposes of this tutorial.
+
+```javascript
+backend "file" {
+  path = "vault"
+}
+
+listener "tcp" {
+  tls_disable = 1
+}
+```
+
+Save this file on disk and then start the Vault server with this command:
+
+```
+$ vault server -config=/etc/vault.conf
+```
+
+At this point, we can use Vault's API for all our interactions. For example, we can initialize Vault like this:
+
+```
+$ curl \
+  -X PUT \
+  -d "{\"secret_shares\":1, \"secret_threshold\":1}" \
+  http://localhost:8200/v1/sys/init
+```
+
+The response should be JSON and look something like this:
+
+```javascript
+{
+  "keys": ["69cf1c12a1f65dddd19472330b28cf4e95c657dfbe545877e5765d25d0592b16"],
+  "root_token": "0e2ede5a-6664-a49e-ca33-8f204d1cdb95"
+}
+```
+
+This response contains our initial root token. It also includes the unseal key. You can use the uneal key to unseal the Vault and use the root token perform other requests in Vault that require authentication.
+
+To make this guide easy to copy-and-paste, we will be using the environment variable `$VAULT_TOKEN` to store the root token. You can export this Vault token in your current shell like this:
+
+```
+$ export VAULT_TOKEN=0e2ede5a-6664-a49e-ca33-8f204d1cdb95
+```
+
+Using the unseal key (not the root token) from above, you can unseal the Vault via the HTTP API:
+
+```
+$ curl \
+  -X PUT \
+  -d '{"key": "69cf1c12a1f65dddd19472330b28cf4e95c657dfbe545877e5765d25d0592b16"}' \
+  http://127.0.0.1:8200/v1/sys/unseal
+```
+
+Note that you should replace `69cf1c1...` with the generated key from your output. This will return a JSON response:
+
+```javascript
+{
+  "sealed": false,
+  "t": 1,
+  "n": 1,
+  "progress": 0
+}
+```
+
+Now we can enable an authentication backend such as [GitHub authentication](/docs/auth/github.html) or [App ID](/docs/auth/app-id.html). For the purposes of this guide, we will enable App ID authentication.
+
+We can enable an authentication backend with the following `curl` command:
+
+```
+$ curl \
+  -X POST \
+  -H "X-Vault-Token:$VAULT_TOKEN" \
+  -d '{"type":"app-id"}' \
+  http://127.0.0.1:8200/v1/sys/auth/app-id
+```
+
+Notice that the request to the app-id endpoint needed an authentication token. In this case we are passing the root token generated when we started the Vault server. We could also generate tokens using any other authentication mechanisms, but we will use the root token for simplicity.
+
+The last thing we need to do before using our App ID endpoint is writing the data to the store to associate an app id with a user id. For more information on this process, see the documentation on the [app-id auth backend](/docs/auth/app-id.html).
+
+First, we need to associate the application with a particular [ACL policy](/docs/concepts/policies.html) in Vault. In the following command, we are going to associate the created tokens with the `root` policy. You would not want to do this in a real production scenario because the root policy allows complete read, write, and administrator access to Vault. For a production application, you should create an ACL policy (which is also possible via the HTTP API), but is not covered in this guide for simplicity.
+
+```
+$ curl \
+  -X POST \
+  -H "X-Vault-Token:$VAULT_TOKEN" \
+  -d '{"value":"root", "display_name":"demo"}' \
+  http://localhost:8200/v1/auth/app-id/map/app-id/152AEA38-85FB-47A8-9CBD-612D645BFACA
+```
+
+Note that `152AEA38-85FB-47A8-9CBD-612D645BFACA` is a randomly generated UUID. You can use any tool to generate a UUID, but make sure it is unique.
+
+Next we need to map the application to a particular "user". In Vault, this is actually a particular application:
+
+```
+$ curl \
+  -X POST \
+  -H "X-Vault-Token:$VAULT_TOKEN" \
+  -d '{"value":"152AEA38-85FB-47A8-9CBD-612D645BFACA"}' \
+  http://localhost:8200/v1/auth/app-id/map/user-id/5ADF8218-D7FB-4089-9E38-287465DBF37E
+```
+
+Now your app can identify itself via the app-id and user-id and get access to Vault. The first step is to authenticate:
+
+```
+$ curl \
+  -X POST \
+  -d '{"app_id":"152AEA38-85FB-47A8-9CBD-612D645BFACA", "user_id": "5ADF8218-D7FB-4089-9E38-287465DBF37E"}' \
+  "http://127.0.0.1:8200/v1/auth/app-id/login"
+```
+
+This will return a response that looks like the following:
+
+```javascript
+{
+  "lease_id": "",
+  "renewable": false,
+  "lease_duration": 0,
+  "data": null,
+  "auth": {
+    "client_token": "7a25c58b-9bad-5750-b579-edbb9f10a5ef",
+    "policies": ["root"],
+    "lease_duration": 0,
+    "renewable": false,
+    "metadata": {
+      "app-id": "sha1:1c0401b419280b0771d006bcdae683989086a00e",
+      "user-id": "sha1:4dbf74fce71648d54c42e28ad193253600853ca6"
+    }
+  }
+}
+```
+
+The returned client token (`7a25c58b-9bad-5750-b579-edbb9f10a5ef`) can now be used to authenticate with Vault. As you can see from the returned payload, the App ID backend does not currently support lease expiration or renewal. If you authenticate with backend that does support leases, your application will have to track expiration and handle renewal, but that is a topic for another guide.
+
+We can export this new token as our new `VAULT_TOKEN`:
+
+```
+$ export VAULT_TOKEN="7a25c58b-9bad-5750-b579-edbb9f10a5ef"
+```
+
+Be sure to replace this with the value returned from your API response. We can now use this token to authentication requests to Vault:
+
+```
+$ curl \
+  -X POST \
+  -H "X-Vault-Token:$VAULT_TOKEN" \
+  -H 'Content-type: application/json' \
+  -d '{"bar":"baz"}' \
+  http://127.0.0.1:8200/v1/secret/foo
+```
+
+This will create a new secret named "foo" with the given JSON contents. We can read this value back with the same token:
+
+```
+$ curl \
+  -H "X-Vault-Token:$VAULT_TOKEN" \
+  http://127.0.0.1:8200/v1/secret/foo
+```
+
+This should return a response like this:
+
+```javascript
+{
+  "lease_id": "secret/foo/cc529d06-36c8-be27-31f5-2390e1f6e2ae",
+  "renewable": false,
+  "lease_duration": 2592000,
+  "data": {
+    "bar": "baz"
+  },
+  "auth": null
+}
+```
+
+You can see the documentation on the [HTTP APIs](/docs/http/index.html) for more details on other available endpoints.
+
+Congratulations! You now know all the basics to get started with Vault.
+
+## Next
+
+Next, we have a page dedicated to
+[next steps](/intro/getting-started/next-steps.html) depending on
+what you would like to achieve.
diff --git a/website/source/intro/getting-started/authentication.html.md b/website/source/intro/getting-started/authentication.html.md
new file mode 100644
index 000000000..6ae058329
--- /dev/null
+++ b/website/source/intro/getting-started/authentication.html.md
@@ -0,0 +1,167 @@
+---
+layout: "intro"
+page_title: "Authentication"
+sidebar_current: "gettingstarted-auth"
+description: |-
+  Authentication to Vault gives a user access to use Vault. Vault can authenticate using multiple methods.
+---
+
+# Authentication
+
+Now that we know how to use the basics of Vault, it is important to understand
+how to authenticate to Vault itself. Up to this point, we haven't had to
+authenticate because starting the Vault server in dev mode automatically logs
+us in as root. In practice, you'll almost always have to manually authenticate.
+
+On this page, we'll talk specifically about _authentication_. On the next
+page, we talk about _authorization_.
+Authentication is the mechanism of assigning an identity to a Vault user.
+The access control and permissions associated with an identity are
+authorization, and will not be covered on this page.
+
+Vault has pluggable authentication backends, making it easy to authenticate
+with Vault using whatever form works best for your organization. On this page
+we'll use the token backend as well as the GitHub backend.
+
+## Tokens
+
+We'll first explain token authentication before going over any other
+authentication backends. Token authentication is enabled by default in
+Vault and cannot be disabled. It is also what we've been using up to this
+point.
+
+When you start a dev server with `vault server -dev`, it outputs your
+_root token_. The root token is the initial access token to configure Vault.
+It has root privileges, so it can perform any operation within Vault.
+We'll cover how to limit privileges in the next section.
+
+You can create more tokens using `vault token-create`:
+
+```
+$ vault token-create
+6c38f603-6441-2161-c543-ee15b7206563
+```
+
+By default, this will create a child token of your current token that
+inherits all the same access control policies. The "child" concept here
+is important: tokens always have a parent, and when that parent token is
+revoked, children can also be revoked all in one operation. This makes it
+easy when removing access for a user, to remove access for all sub-tokens
+that user created as well.
+
+After a token is created, you can revoke it with `vault token-revoke`:
+
+```
+$ vault token-revoke 6c38f603-6441-2161-c543-ee15b7206563
+Revocation successful.
+```
+
+In a previous section, we use the `vault revoke` command. This command
+is only used for revoking _secrets_. For revoking _tokens_, the
+`vault token-revoke` command must be used.
+
+To authenticate with a token, use the `vault auth` command:
+
+```
+$ vault auth d08e2bd5-ffb0-440d-6486-b8f650ec8c0c
+Successfully authenticated! The policies that are associated
+with this token are listed below:
+
+root
+```
+
+This authenticates with Vault. It will verify your token and let you know
+what access policies the token is associated with. If you want to test
+`vault auth`, make sure you create a new token first.
+
+## Auth Backends
+
+In addition to tokens, other authentication backends can be enabled.
+Authentication backends enable alternate methods of identifying with Vault.
+These identities are tied back to a set of access policies, just like tokens.
+
+Vault supports other authentication backends in order to make authentication
+easiest for your environment. For example, for desktop environments,
+private key or GitHub based authentication may be easiest. For server
+environments, some shared secret may be best. Auth backends give you
+flexibility to choose what authentication you want to use.
+
+As an example, let's authenticate using GitHub. First, enable the
+GitHub authentication backend:
+
+```
+$ vault auth-enable github
+Successfully enabled 'github' at 'github'!
+```
+
+Auth backends are mounted, just like secret backends, except auth
+backends are always prefixed with `auth/`. So the GitHub backend we just
+mounted can be accessed at `auth/github`. You can use `vault path-help` to
+learn more about it.
+
+With the backend enabled, we first have to configure it. For GitHub,
+we tell it what organization users must part of, and map a team to a policy:
+
+```
+$ vault write auth/github/config organization=hashicorp
+Success! Data written to: auth/github/config
+
+$ vault write auth/github/map/teams/default value=root
+Success! Data written to: auth/github/map/teams/default
+```
+
+The above configured our GitHub backend to only accept users from the
+"hashicorp" organization (you should fill in your own organization)
+and to map any team to the "root" policy, which is the only policy we have
+right now until the next section.
+
+With GitHub enabled, we can authenticate using `vault auth`:
+
+```
+$ vault auth -method=github token=e6919b17dd654f2b64e67b6369d61cddc0bcc7d5
+Successfully authenticated! The policies that are associated
+with this token are listed below:
+
+root
+```
+
+Success! We've authenticated using GitHub. The "root" policy was associated
+with my identity since we mapped that earlier. The value for "token" should be your own
+[personal access token](https://help.github.com/articles/creating-an-access-token-for-command-line-use/).
+
+You can revoke authentication from any authentication backend using
+`vault token-revoke` as well, which can revoke any path prefix. For
+example, to revoke all GitHub tokens, you could run the following.
+**Don't run this unless you have access to another root token or you'll
+get locked out.**
+
+```
+$ vault token-revoke -mode=path auth/github
+```
+
+When you're done, you can disable authentication backends with
+`vault auth-disable`. This will immediately invalidate all authenticated
+users from this backend.
+
+```
+$ vault auth-disable github
+Disabled auth provider at path 'github'!
+```
+
+If you ran the above, you'll probably find you can't access your Vault
+anymore unless you have another root token, since it invalidated your
+own session since we authenticated with GitHub above. Since we're still
+operating in development mode, just restart the dev server to fix this.
+
+## Next
+
+In this page you learned about how Vault authenticates users. You learned
+about the built-in token system as well as enabling other authentication
+backends. At this point you know how Vault assigns an _identity_ to
+a user.
+
+The multiple authentication backends Vault provides let you choose the
+most appropriate authentication mechanism for your organization.
+
+In this next section, we'll learn about
+[access control policies](/intro/getting-started/acl.html).
diff --git a/website/source/intro/getting-started/deploy.html.md b/website/source/intro/getting-started/deploy.html.md
new file mode 100644
index 000000000..14aef2d9f
--- /dev/null
+++ b/website/source/intro/getting-started/deploy.html.md
@@ -0,0 +1,222 @@
+---
+layout: "intro"
+page_title: "Deploy Vault"
+sidebar_current: "gettingstarted-deploy"
+description: |-
+  Learn how to deploy Vault into production, how to initialize it, configure it, etc.
+---
+
+# Deploy Vault
+
+Up to this point, we've been working with the dev server, which
+automatically authenticated us, setup in-memory storage, etc. Now that
+you know the basics of Vault, it is important to learn how to deploy
+Vault into a real environment.
+
+On this page, we'll cover how to configure Vault, start Vault, the
+seal/unseal process, and scaling Vault.
+
+## Configuring Vault
+
+Vault is configured using [HCL](https://github.com/hashicorp/hcl) files.
+As a reminder, these files are also JSON-compatible. The configuration
+file for Vault is relatively simple. An example is shown below:
+
+```javascript
+backend "consul" {
+  address = "127.0.0.1:8500"
+  path = "vault"
+}
+
+listener "tcp" {
+ address = "127.0.0.1:8200"
+ tls_disable = 1
+}
+```
+
+Within the configuration file, there are two primary configurations:
+
+  * `backend` - This is the physical backend that Vault uses for
+    storage. Up to this point the dev server has used "inmem" (in memory),
+    but in the example above we're using [Consul](http://www.consul.io),
+    a much more production-ready backend.
+
+  * `listener` - One or more listeners determine how Vault listens for
+    API requests. In the example above we're listening on localhost port
+    8200 without TLS.
+
+For now, copy and paste the configuration above to `example.hcl`. It will
+configure Vault to expect an instance of Consul running locally.
+
+Starting a local Consul instance takes only a few minutes. Just follow the
+[Consul Getting Started Guide](https://www.consul.io/intro/getting-started/install.html)
+up to the point where you have installed Consul and started it with this command:
+
+```shell
+$ consul agent -server -bootstrap-expect 1 -data-dir /tmp/consul
+```
+
+## Starting the Server
+
+With the configuration in place, starting the server is simple, as
+shown below. Modify the `-config` flag to point to the proper path
+where you saved the configuration above.
+
+```
+$ vault server -config=example.hcl
+==> Vault server configuration:
+
+         Log Level: info
+           Backend: consul
+        Listener 1: tcp (addr: "127.0.0.1:8200", tls: "disabled")
+
+==> Vault server started! Log data will stream in below:
+```
+
+Vault outputs some information about its configuration, and then blocks.
+This process should be run using a resource manager such as systemd or
+upstart.
+
+You'll notice that you can't execute any commands. We don't have any
+auth information! When you first setup a Vault server, you have to start
+by _initializing_ it.
+
+On Linux, Vault may fail to start with the following error:
+
+```shell
+$ vault server -config=example.hcl
+Error initializing core: Failed to lock memory: cannot allocate memory
+
+This usually means that the mlock syscall is not available.
+Vault uses mlock to prevent memory from being swapped to
+disk. This requires root privileges as well as a machine
+that supports mlock. Please enable mlock on your system or
+disable Vault from using it. To disable Vault from using it,
+set the `disable_mlock` configuration option in your configuration
+file.
+```
+
+For guidance on dealing with this issue, see the discussion of
+`disable_mlock` in [Server Configuration](/docs/config/index.html).
+
+## Initializing the Vault
+
+Initialization is the process of first configuring the Vault. This
+only happens once when the server is started against a new backend that
+has never been used with Vault before.
+
+During initialization, the encryption keys are generated, unseal keys
+are created, and the initial root token is setup. To initialize Vault
+use `vault init`. This is an _unauthenticated_ request, but it only works
+on brand new Vaults with no data:
+
+```
+$ vault init
+Key 1: 427cd2c310be3b84fe69372e683a790e01
+Key 2: 0e2b8f3555b42a232f7ace6fe0e68eaf02
+Key 3: 37837e5559b322d0585a6e411614695403
+Key 4: 8dd72fd7d1af254de5f82d1270fd87ab04
+Key 5: b47fdeb7dda82dbe92d88d3c860f605005
+Initial Root Token: eaf5cc32-b48f-7785-5c94-90b5ce300e9b
+
+Vault initialized with 5 keys and a key threshold of 3!
+
+Please securely distribute the above keys. Whenever a Vault server
+is started, it must be unsealed with 3 (the threshold)
+of the keys above (any of the keys, as long as the total number equals
+the threshold).
+
+Vault does not store the original master key. If you lose the keys
+above such that you no longer have the minimum number (the
+threshold), then your Vault will not be able to be unsealed.
+```
+
+Initialization outputs two incredibly important pieces of information:
+the _unseal keys_ and the _initial root token_. This is the
+**only time ever** that all of this data is known by Vault, and also the
+only time that the unseal keys should ever be so close together.
+
+For the purpose of this getting started guide, save all these keys
+somewhere, and continue. In a real deployment scenario, you would never
+save these keys together.
+
+## Seal/Unseal
+
+Every initialized Vault server starts in the _sealed_ state. From
+the configuration, Vault can access the physical storage, but it can't
+read any of it because it doesn't know how to decrypt it. The process
+of teaching Vault how to decrypt the data is known as _unsealing_ the
+Vault.
+
+Unsealing has to happen every time Vault starts. It can be done via
+the API and via the command line. To unseal the Vault, you
+must have the _threshold_ number of unseal keys. In the output above,
+notice that the "key threshold" is 3. This means that to unseal
+the Vault, you need 3 of the 5 keys that were generated.
+
+-> **Note:** Vault does not store any of the unseal key shards. Vault
+uses an algorithm known as
+[Shamir's Secret Sharing](http://en.wikipedia.org/wiki/Shamir%27s_Secret_Sharing)
+to split the master key into shards. Only with the threshold number of keys
+can it be reconstructed and your data finally accessed.
+
+Begin unsealing the Vault with `vault unseal`:
+
+```
+$ vault unseal
+Key (will be hidden):
+Sealed: true
+Key Shares: 5
+Key Threshold: 3
+Unseal Progress: 1
+```
+
+After pasting in a valid key and confirming, you'll see that the Vault
+is still sealed, but progress is made. Vault knows it has 1 key out of 3.
+Due to the nature of the algorithm, Vault doesn't know if it has the
+_correct_ key until the threshold is reached.
+
+Also notice that the unseal process is stateful. You can go to another
+computer, use `vault unseal`, and as long as it's pointing to the same server,
+that other computer can continue the unseal process. This is incredibly
+important to the design of the unseal process: multiple people with multiple
+keys are required to unseal the Vault. The Vault can be unsealed from
+multiple computers and the keys should never be together. A single malicious
+operator does not have enough keys to be malicious.
+
+Continue with `vault unseal` to complete unsealing the Vault. Note that
+all 3 keys must be different, but they can be any other keys. As long as
+they're correct, you should soon see output like this:
+
+```
+$ vault unseal
+Key (will be hidden):
+Sealed: false
+Key Shares: 5
+Key Threshold: 3
+Unseal Progress: 0
+```
+
+The `Sealed: false` means the Vault is unsealed!
+
+Feel free to play around with entering invalid keys, keys in different
+orders, etc. in order to understand the unseal process. It is very important.
+Once you're ready to move on, use `vault auth` to authenticate with
+the root token.
+
+As a root user, you can reseal the Vault with `vault seal`. A single
+operator is allowed to do this. This lets a single operator lock down
+the Vault in an emergency without consulting other operators.
+
+When the Vault is sealed again, it clears all of its state (including
+the encryption key) from memory. The Vault is secure and locked down
+from access.
+
+## Next
+
+You now know how to configure, initialize, and unseal/seal Vault.
+This is the basic knowledge necessary to deploy Vault into a real
+environment. Once the Vault is unsealed, you access it as you have
+throughout this getting started guide (which worked with an unsealed Vault).
+
+Next, we have a [short tutorial](/intro/getting-started/apis.html) on using the HTTP APIs to authenticate and access secrets.
diff --git a/website/source/intro/getting-started/dev-server.html.md b/website/source/intro/getting-started/dev-server.html.md
new file mode 100644
index 000000000..21a6251e2
--- /dev/null
+++ b/website/source/intro/getting-started/dev-server.html.md
@@ -0,0 +1,113 @@
+---
+layout: "intro"
+page_title: "Starting the Server"
+sidebar_current: "gettingstarted-devserver"
+description: |-
+  After installing Vault, the next step is to start the server.
+---
+
+# Starting the Vault Server
+
+With Vault installed, the next step is to start a Vault server.
+
+Vault operates as a client/server application. The Vault server is the
+only piece of the Vault architecture that interacts with the data
+storage and backends. All operations done via the Vault CLI interact
+with the server over a TLS connection.
+
+In this page, we'll start and interact with the Vault server to understand
+how the server is started, and understanding the seal/unseal process.
+
+## Starting the Dev Server
+
+To start, we're going to start the Vault _dev server_. The dev server
+is a built-in flag to start a pre-configured server that is not very
+secure but useful for playing with Vault locally. Later in the getting
+started guide we'll configure and start a real server.
+
+To start the Vault dev server, run `vault server -dev`:
+
+```
+$ vault server -dev
+WARNING: Dev mode is enabled!
+
+In this mode, Vault is completely in-memory and unsealed.
+Vault is configured to only have a single unseal key. The root
+token has already been authenticated with the CLI, so you can
+immediately begin using the Vault CLI.
+
+The only step you need to take is to set the following
+environment variable since Vault will be talking without TLS:
+
+    export VAULT_ADDR='http://127.0.0.1:8200'
+
+The unseal key and root token are reproduced below in case you
+want to seal/unseal the Vault or play with authentication.
+
+Unseal Key: 2252546b1a8551e8411502501719c4b3
+Root Token: 79bd8011-af5a-f147-557e-c58be4fedf6c
+
+==> Vault server configuration:
+
+         Log Level: info
+           Backend: inmem
+        Listener 1: tcp (addr: "127.0.0.1:8200", tls: "disabled")
+
+...
+```
+
+You should see output similar to that above. As you can see, when you
+start a dev server, Vault warns you loudly. The dev server stores all
+its data in-memory (but still encrypted), listens on localhost without TLS, and
+automatically unseals and shows you the unseal key and root access key.
+We'll go over what all this means shortly.
+
+The important thing about the dev server is that it is meant for
+development only. **Do not run the dev server in production.** Even if it
+was run in production, it wouldn't be very useful since it stores data in-memory
+and every restart would clear all your secrets.
+
+With the dev server running, do the following three things before anything
+else:
+
+  1. Copy and run the `export VAULT_ADDR ...` command from your terminal
+     output. This will configure the Vault client to talk to our dev server.
+
+  2. Save the unseal key somewhere. Don't worry about _how_ to save this
+     securely. For now, just save it anywhere.
+
+  3. Do the same as step 2, but with the root token. We'll use this later.
+
+## Verify the Server is Running
+
+Verify the server is running by running `vault status`. This should
+succeed and exit with exit code 0. If you see an error about opening
+a connection, make sure you copied and executed the `export VAULT_ADDR...`
+command from above properly.
+
+If it ran successful, the output should look like below:
+
+```
+$ vault status
+Sealed: false
+Key Shares: 1
+Key Threshold: 1
+Unseal Progress: 0
+
+High-Availability Enabled: false
+```
+
+If the output looks different, especially if the numbers are different
+or the Vault is sealed, then restart the dev server and try again. The
+only reason these would ever be different is if you're running a dev
+server from going through this guide previously.
+
+We'll cover what this output means later in the guide.
+
+## Next
+
+Congratulations! You've started your first Vault server. We haven't stored
+any secrets yet, but we'll do that in the next section.
+
+Next, we're going to
+[read and write our first secrets](/intro/getting-started/first-secret.html).
diff --git a/website/source/intro/getting-started/dynamic-secrets.html.md b/website/source/intro/getting-started/dynamic-secrets.html.md
new file mode 100644
index 000000000..2ef584735
--- /dev/null
+++ b/website/source/intro/getting-started/dynamic-secrets.html.md
@@ -0,0 +1,172 @@
+---
+layout: "intro"
+page_title: "Dynamic Secrets"
+sidebar_current: "gettingstarted-dynamicsecrets"
+description: |-
+  On this page we introduce dynamic secrets by showing you how to create AWS access keys with Vault.
+---
+
+# Dynamic Secrets
+
+Now that we've written basic secrets to Vault and we have an understanding
+of the mount system, we're going to move on to the next core feature of
+Vault: _dynamic secrets_.
+
+Dynamic secrets are secrets that are generated when they're accessed,
+and aren't statically written like we did in
+[Your First Secret](/intro/getting-started/first-secret.html).
+On this page, we'll use the built-in AWS secret backend to dynamically
+generate AWS access keys.
+
+The power of dynamic secrets is that they simply don't exist before
+they're read, so there is no risk of someone stealing them or another
+client using the same secrets. And because Vault has built-in revocation
+mechanisms (covered later), the dynamic secret can be revoked right after
+use, minimizing the amount of time the secret existed.
+
+-> **Note:** Before starting this page, please register for an
+[AWS account](http://aws.amazon.com). We won't be using any features that
+cost money, so you shouldn't be charged for anything. However, we're not
+responsible for any charges you may incur.
+
+## Mounting the AWS Backend
+
+Let's generate our first dynamic secret. We'll use the AWS backend to
+dynamically generate an AWS access key pair. First, mount the AWS backend:
+
+```
+$ vault mount aws
+Successfully mounted 'aws' at 'aws'!
+```
+
+The AWS backend is now mounted at `aws/`. As we covered in a previous
+section: different secret backends allow for different behavior, and in this
+case the AWS backend is a dynamic backend for generating AWS access credentials.
+
+## Configuring the AWS Backend
+
+With the AWS backend mounted, the first step is to configure it with
+the AWS credentials that will be used to create the other credentials.
+For now, use the root keys for your AWS account.
+
+To configure the backend, we use `vault write` to a special path
+`aws/config/root`:
+
+```
+$ vault write aws/config/root \
+    access_key=AKIAI4SGLQPBX6CSENIQ \
+    secret_key=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
+Success! Data written to: aws/config/root
+```
+
+Remember that secret backends can behave anyway they want when
+reading/writing a path, so this path stores this configuration for
+later. Notice you can't read it back:
+
+```
+$ vault read aws/config/root
+Error reading aws/config/root: Error making API request.
+
+URL: GET http://127.0.0.1:8200/v1/aws/config/root
+Code: 500. Errors:
+
+* unsupported operation
+```
+
+To help keep the credentials secure, the AWS backend doesn't let you
+read them back even if you're using a root credential.
+
+## Creating a Role
+
+The next step is to configure the AWS backend with an IAM policy.
+IAM is the system AWS uses for creating new credentials with limited
+API permissions.
+
+The AWS backend requires an IAM policy to associate created credentials
+with. For this example, we'll write just one policy, but you can associate
+many policies with the backend. Save a file named "policy.json" with the following contents:
+
+```javascript
+{
+  "Version": "2012-10-17",
+  "Statement": [
+    {
+      "Sid": "Stmt1426528957000",
+      "Effect": "Allow",
+      "Action": [
+        "ec2:*"
+      ],
+      "Resource": [
+        "*"
+      ]
+    }
+  ]
+}
+```
+
+This is a basic IAM policy that lets the user perform any action within
+Amazon EC2. With the policy saved, write it to Vault and create a new role:
+
+```
+$ vault write aws/roles/deploy policy=@policy.json
+Success! Data written to: aws/roles/deploy
+```
+
+Again, we're using a special path here `aws/roles/<NAME>` to write
+an IAM policy to Vault. We also used the special syntax `@filename` with
+`vault write` to write the contents of a file.
+
+## Generating the Secret
+
+Now that we've configured the AWS backend and created a role, we can now
+request an access key pair for that role. To do so, just read the
+special path `aws/creds/<NAME>` where `NAME` is the role name:
+
+```
+$ vault read aws/creds/deploy
+Key         Value
+lease_id    aws/creds/deploy/0d042c53-aa8a-7ce7-9dfd-310351c465e5
+access_key  AKIAJFN42DVCQWDHQYHQ
+secret_key  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
+```
+
+Success! The access and secret key can now be used to perform any EC2
+operations within AWS. You can verify they work, if you want. Also notice
+that these keys are new, they're not the keys you entered earlier.
+
+The `lease_id` above is a special ID used for Vault for renewal,
+revocation, etc. Copy and save your Lease ID now.
+
+## Revoking the Secret
+
+Let's complete the loop and revoke this secret now, purging it from
+existence. Once the secret is revoked, the access keys will no longer
+work.
+
+To revoke the secret, use `vault revoke` with the lease ID that was
+outputted from `vault read` when you ran it:
+
+```
+$ vault revoke aws/creds/deploy/0d042c53-aa8a-7ce7-9dfd-310351c465e5
+Key revoked with ID 'aws/creds/deploy/0d042c53-aa8a-7ce7-9dfd-310351c465e5'.
+```
+
+Done! If you look at your AWS account, you'll notice that no IAM users
+exist. If you try to use the access keys that were generated, you'll
+find that they no longer work.
+
+With such easy dynamic creation and revocation, you can hopefully begin
+to see how easy it is to work with dynamic secrets and ensure they only
+exist for the duration that they're needed.
+
+## Next
+
+On this page we experienced our first dynamic secret, and we also saw
+the revocation system in action. Dynamic secrets are incredibly powerful.
+As time goes on, we expect that more systems will support some sort of
+API to create access credentials, and Vault will be ready to get the
+most value out of this practice.
+
+Before going further, we're going to take a quick detour to learn
+about the
+[built-in help system](/intro/getting-started/help.html).
diff --git a/website/source/intro/getting-started/first-secret.html.md b/website/source/intro/getting-started/first-secret.html.md
new file mode 100644
index 000000000..dea0b463e
--- /dev/null
+++ b/website/source/intro/getting-started/first-secret.html.md
@@ -0,0 +1,118 @@
+---
+layout: "intro"
+page_title: "Your First Secret"
+sidebar_current: "gettingstarted-firstsecret"
+description: |-
+  With the Vault server running, let's read and write our first secret.
+---
+
+# Your First Secret
+
+Now that the dev server is up and running, let's get straight to it and
+read and write our first secret.
+
+One of the core features of Vault is the ability to read and write
+arbitrary secrets securely. On this page, we'll do this using the CLI,
+but there is also a complete
+[HTTP API](/docs/http/index.html)
+that can be used to programmatically do anything with Vault.
+
+Secrets written to Vault are encrypted and then written to the backend
+storage. For our dev server, backend storage is in-memory, but in production
+this would more likely be on disk or in [Consul](https://www.consul.io).
+Vault encrypts the value before it is ever handed to the storage driver.
+The backend storage mechanism _never_ sees the unencrypted value and doesn't
+have the means necessary to decrypt it without Vault.
+
+## Writing a Secret
+
+Let's start by writing a secret. This is done very simply with the
+`vault write` command, as shown below:
+
+```
+$ vault write secret/hello value=world
+Success! Data written to: secret/hello
+```
+
+This writes the pair `value=world` to the path `secret/hello`. We'll
+cover paths in more detail later, but for now it is important that the
+path is prefixed with `secret/`, otherwise this example won't work. The
+`secret/` prefix is where arbitrary secrets can be read and written.
+
+You can even write multiple pieces of data, if you want:
+
+```
+$ vault write secret/hello value=world excited=yes
+Success! Data written to: secret/hello
+```
+
+`vault write` is a very powerful command. In addition to writing data
+directly from the command-line, it can read values and keypairs from
+stdin as well as files. For more information, see the
+[vault write documentation](/docs/commands/read-write.html).
+
+~> **Warning:** The documentation uses the "key=value" based entry
+throughout, but it is more secure to use files if possible. Sending
+data via the CLI is often logged in shell history. For real secrets,
+please use files. See the link above for more information.
+
+## Reading a Secret
+
+As you might expect, secrets can be read with `vault read`:
+
+```
+$ vault read secret/hello
+Key             Value
+lease_id        secret/hello/d57fe039-1eef-9f4a-f3c9-63e2b29002b8
+lease_duration  2592000
+excited         yes
+value           world
+```
+
+As you can see, the values we wrote are given back to us. Vault read
+the data from storage and decrypted it.
+The output format is purposefully whitespace separated to make it easy
+to pipe into a tool like `awk`.
+
+In addition to the tabular format, if you're working with machines or
+a tool like `jq`, you can output the data in JSON format:
+
+```
+$ vault read -format=json secret/hello
+{
+  "lease_id": "secret/hello/25f33857-15ed-b62b-dac6-4b29bb8e8bef",
+  "lease_duration": 2592000,
+  "renewable": false,
+  "data": {
+    "excited": "yes",
+    "value": "world"
+  }
+}
+```
+
+This contains some extra information, but you can see our data mirrored
+here as well. The JSON output is very useful for scripts. For example below
+we use the `jq` tool to extract the "excited" value:
+
+```
+$ vault read -format=json secret/hello | jq -r .data.excited
+yes
+```
+
+## Deleting a Secret
+
+Now that we've learned how to read and write a secret, let's go ahead
+and delete it. We can do this with `vault delete`:
+
+```
+$ vault delete secret/hello
+Success! Deleted 'secret/hello'
+```
+
+## Next
+
+In this section we learned how to use the powerful CRUD features of
+Vault to store arbitrary secrets. On its own this is already a useful
+but basic feature.
+
+Next, we'll learn the basics about [secret backends](/intro/getting-started/secret-backends.html).
diff --git a/website/source/intro/getting-started/help.html.md b/website/source/intro/getting-started/help.html.md
new file mode 100644
index 000000000..523a7ce58
--- /dev/null
+++ b/website/source/intro/getting-started/help.html.md
@@ -0,0 +1,121 @@
+---
+layout: "intro"
+page_title: "Built-in Help"
+sidebar_current: "gettingstarted-help"
+description: |-
+  Vault has a built-in help system to learn about the available paths in Vault and how to use them.
+---
+
+# Built-in Help
+
+You've now worked with `vault write` and `vault read` for multiple paths:
+generic secret backend with `secret/` and dynamic AWS credentials with the
+AWS backend provider at `aws/`. In both cases, the usage of read/write and
+the paths to use differed. AWS in particular had special paths like
+`aws/config`.
+
+Instead of having to memorize or reference documentation constantly
+to determine what paths to use, we built a help system directly into
+Vault. This help system can be accessed via the API or the command-line and
+generates human-readable help for any mounted backend.
+
+On this page, we'll learn how to use this help system. It is an invaluable
+tool as you continue to work with Vault.
+
+## Backend Overview
+
+For this, we'll assume you have the AWS backend mounted. If not, mount
+it with `vault mount aws`. Even if you don't have an AWS account, you
+can still mount the AWS backend.
+
+With the backend mounted, let's learn about it with `vault path-help`:
+
+```
+$ vault path-help aws
+## DESCRIPTION
+
+The AWS backend dynamically generates AWS access keys for a set of
+IAM policies. The AWS access keys have a configurable lease set and
+are automatically revoked at the end of the lease.
+
+After mounting this backend, credentials to generate IAM keys must
+be configured with the "root" path and policies must be written using
+the "roles/" endpoints before any access keys can be generated.
+
+## PATHS
+
+The following paths are supported by this backend. To view help for
+any of the paths below, use the help command with any route matching
+the path pattern. Note that depending on the policy of your auth token,
+you may or may not be able to access certain paths.
+
+    ^config/lease$
+        Configure the default lease information for generated credentials.
+
+    ^config/root$
+        Configure the root credentials that are used to manage IAM.
+
+    ^creds/(?P<name>\w+)$
+        Generate an access key pair for a specific role.
+
+    ^roles/(?P<name>\w+)$
+        Read and write IAM policies that access keys can be made for.
+```
+
+The `vault path-help` command takes a path. By specifying the root path for
+a mount, it will give us the overview of that mount. Notice how the help
+not only contains a description, but also the exact regular expressions
+used to match routes for this backend along with a brief description
+of what the route is for.
+
+## Path Help
+
+After seeing the overview, we can continue to dive deeper by getting
+help for an individual path. For this, just use `vault path-help` with a path
+that would match the regular expression for that path. Note that the path
+doesn't need to actually _work_. For example, we'll get the help below
+for accessing `aws/creds/operator`, even though we never created the `operator`
+role:
+
+```
+$ vault path-help aws/creds/operator
+Request:        creds/operator
+Matching Route: ^creds/(?P<name>\w+)$
+
+Generate an access key pair for a specific role.
+
+## PARAMETERS
+
+    name (string)
+        Name of the role
+
+## DESCRIPTION
+
+This path will generate a new, never before used key pair for
+accessing AWS. The IAM policy used to back this key pair will be
+the "name" parameter. For example, if this backend is mounted at "aws",
+then "aws/creds/deploy" would generate access keys for the "deploy" role.
+
+The access keys will have a lease associated with them. The access keys
+can be revoked by using the lease ID.
+```
+
+Within a path, we're given the parameters that this path requires.
+Some parameters come from the route itself. In this case, the "name"
+parameter is a named capture from the route regular expression.
+
+There is also a description of what that path does.
+
+Go ahead and explore more paths! Mount other backends, traverse their
+help systems and learn about what they do. For example, learn about the
+generic `secret/` path.
+
+## Next
+
+The help system may not be the most exciting feature of Vault, but it
+is indispensable in day-to-day usage of Vault. The help system lets you
+learn about how to use any backend within Vault without leaving the command
+line.
+
+Next, we'll learn about
+[authentication](/intro/getting-started/authentication.html).
diff --git a/website/source/intro/getting-started/install.html.md b/website/source/intro/getting-started/install.html.md
new file mode 100644
index 000000000..e73aedabb
--- /dev/null
+++ b/website/source/intro/getting-started/install.html.md
@@ -0,0 +1,83 @@
+---
+layout: "intro"
+page_title: "Install Vault"
+sidebar_current: "gettingstarted-install"
+description: |-
+  The first step to using Vault is to get it installed.
+---
+
+# Install Vault
+
+Vault must first be installed on your machine. Vault is distributed as
+a [binary package](/downloads.html) for all supported platforms and
+architectures. This page will not cover how to compile Vault from source,
+but compiling from source is covered in the [documentation](/docs/install/index.html)
+for those who want to be sure they're compiling source they trust into
+the final binary.
+
+## Installing Vault
+
+To install Vault, find the [appropriate package](/downloads.html) for
+your system and download it. Vault is packaged as a zip archive.
+
+After downloading Vault, unzip the package. Vault runs as a single binary
+named `vault`. Any other files in the package can be safely removed and
+Vault will still function.
+
+The final step is to make sure that `vault` is available on the PATH.
+See [this page](http://stackoverflow.com/questions/14637979/how-to-permanently-set-path-on-linux)
+for instructions on setting the PATH on Linux and Mac.
+[This page](http://stackoverflow.com/questions/1618280/where-can-i-set-path-to-make-exe-on-windows)
+contains instructions for setting the PATH on Windows.
+
+## Verifying the Installation
+
+After installing Vault, verify the installation worked by opening a new
+terminal session and checking that `vault` is available. By executing
+`vault`, you should see help output similar to the following:
+
+```
+$ vault
+usage: vault [-version] [-help] <command> [args]
+
+Common commands:
+    delete           Delete operation on secrets in Vault
+    path-help        Look up the help for a path
+    read             Read data or secrets from Vault
+    renew            Renew the lease of a secret
+    revoke           Revoke a secret.
+    server           Start a Vault server
+    status           Outputs status of whether Vault is sealed and if HA mode is enabled
+    write            Write secrets or configuration into Vault
+
+All other commands:
+    audit-disable    Disable an audit backend
+    audit-enable     Enable an audit backend
+    audit-list       Lists enabled audit backends in Vault
+    auth             Prints information about how to authenticate with Vault
+    auth-disable     Disable an auth provider
+    auth-enable      Enable a new auth provider
+    init             Initialize a new Vault server
+    key-status       Provides information about the active encryption key
+    mount            Mount a logical backend
+    mounts           Lists mounted backends in Vault
+    policies         List the policies on the server
+    policy-delete    Delete a policy from the server
+    policy-write     Write a policy to the server
+    rekey            Rekeys Vault to generate new unseal keys
+    remount          Remount a secret backend to a new path
+    rotate           Rotates the backend encryption key used to persist data
+    seal             Seals the vault server
+    token-create     Create a new auth token
+    token-renew      Renew an auth token
+    token-revoke     Revoke one or more auth tokens
+    unmount          Unmount a secret backend
+    unseal           Unseals the vault server
+    version          Prints the Vault version
+```
+
+If you get an error that Vault could not be found, then your PATH environment
+variable was not setup properly. Please go back and ensure that your PATH
+variable contains the directory where Vault was installed.
+
+Otherwise, Vault is installed and ready to go!
diff --git a/website/source/intro/getting-started/next-steps.html.md b/website/source/intro/getting-started/next-steps.html.md
new file mode 100644
index 000000000..3e6b0e0d9
--- /dev/null
+++ b/website/source/intro/getting-started/next-steps.html.md
@@ -0,0 +1,20 @@
+---
+layout: "intro"
+page_title: "Next Steps"
+sidebar_current: "gettingstarted-nextsteps"
+description: |-
+  After completing the getting started guide, learn about what to do next with Vault.
+---
+
+# Next Steps
+
+That concludes the getting started guide for Vault. Hopefully you're
+excited about the possibilities of Vault and ready to put this knowledge
+to use to improve your environment.
+
+We've covered the basics of all the core features of Vault in this guide.
+Due to the importance of securing secrets, we recommend reading the following
+as next steps.
+
+  * [Documentation](/docs/index.html) - The documentation is an in-depth
+    reference guide to all the features of Vault.
diff --git a/website/source/intro/getting-started/secret-backends.html.md b/website/source/intro/getting-started/secret-backends.html.md
new file mode 100644
index 000000000..14f32cf2c
--- /dev/null
+++ b/website/source/intro/getting-started/secret-backends.html.md
@@ -0,0 +1,119 @@
+---
+layout: "intro"
+page_title: "Secret Backends"
+sidebar_current: "gettingstarted-secretbackends"
+description: |-
+  Secret backends are what create, read, update, and delete secrets.
+---
+
+# Secret Backends
+
+Previously, we saw how to read and write arbitrary secrets to Vault.
+To do this, we used the `secret/` prefix. This prefix specifies the
+_secret backend_ to use, and Vault defaults to mounting the _generic_
+backend to `secret/`. The generic backend reads and writes raw data to
+the backend storage.
+
+Vault supports other backends in addition to "generic", and this feature
+in particular is what makes Vault unique. For example, the "aws" backend
+generates AWS access keys dynamically, on demand. Another example --
+this type of backend does not yet exist -- is a backend that
+reads and writes data directly to an
+[HSM](http://en.wikipedia.org/wiki/Hardware_security_module).
+As Vault matures, more and more backends will be added.
+
+To represent backends, Vault behaves much like a filesystem: backends
+are _mounted_ at specific paths. For example, the "generic" backend is
+_mounted_ at the `secret/` prefix.
+
+On this page, we'll learn about the mount system and the operations
+that can be performed with them. We do this as prerequisite knowledge
+to the next page, where we'll create dynamic secrets.
+
+## Mount a Backend
+
+To start, let's mount another "generic" backend. Just like a normal
+filesystem, Vault can mount a backend multiple times at different
+mount points. This is useful if you want different access control policies
+(covered later) or configurations for different paths.
+
+To mount the backend:
+
+```
+$ vault mount generic
+Successfully mounted 'generic' at 'generic'!
+```
+
+By default, the mount point will be the same name as the backend. This
+is because 99% of the time, you don't want to customize this mount point.
+In this example, we mounted the "generic" backend at `generic/`.
+
+You can inspect mounts using `vault mounts`:
+
+```
+$ vault mounts
+Path      Type     Description
+generic/  generic
+secret/   generic  generic secret storage
+sys/      system   system endpoints used for control, policy and debugging
+```
+
+You can see the `generic/` path we just mounted, as well as the built-in
+secret path. You can also see the `sys/` path. We won't cover this in the
+getting started guide, but this mount point is used to interact with
+the Vault core system.
+
+Spend some time reading and writing secrets to the new mount point to
+convince yourself it works. As a bonus, write to the `secret/` endpoint
+and observe that those values are unavailable via `generic/`: they share the
+same backend, but do not share any data. In addition to this, backends
+(of the same type or otherwise) _cannot_ access the data of other backends;
+they can only access data within their mount point.
+
+## Unmount a Backend
+
+Once you're sufficiently convinced mounts behave as you expect, you can
+unmount it. When a backend is unmounted, all of its secrets are revoked
+and its data is deleted. If either of these operations fail, the backend
+remains mounted.
+
+```
+$ vault unmount generic/
+Successfully unmounted 'generic/'!
+```
+
+In addition to unmounting, you can _remount_ a backend. Remounting a
+backend changes its mount point. This is still a disruptive command: the
+stored data is retained, but all secrets are revoked since secrets are
+closely tied to their mount paths.
+
+## What is a Secret Backend?
+
+Now that you've mounted and unmounted a backend, you might wonder:
+"what is a secret backend? what is the point of this mounting system?"
+
+Vault behaves a lot like a [virtual filesystem](http://en.wikipedia.org/wiki/Virtual_file_system).
+The read/write/delete operations are forwarded to the backend, and the
+backend can choose to react to these operations however it wishes.
+For example, the "generic" backend simply passes this through to the
+storage backend (after encrypting data first).
+
+However, the "aws" backend (which you'll see soon), will read/write IAM
+policies and access tokens. So, while you might do a `vault read aws/deploy`,
+this isn't reading from any _physical_ path "aws/deploy". Instead, the AWS
+backend is dynamically generating an access key based on the "deploy" policy.
+
+This abstraction is incredibly powerful. It lets Vault interface directly
+with physical systems such as the backend as well as things such as SQL
+databases, HSMs, etc. But in addition to these physical systems, Vault
+can interact with more unique environments: AWS IAM, dynamic SQL user creation,
+etc. all using the same read/write interface.
+
+## Next
+
+You now know about secret backends and how to operate on the mount table.
+This is important knowledge to move forward and learn about other secret
+backends.
+
+Next, we'll use the
+[AWS backend to generate dynamic secrets](/intro/getting-started/dynamic-secrets.html).
diff --git a/website/source/intro/index.html.markdown b/website/source/intro/index.html.markdown
new file mode 100644
index 000000000..f6296cf18
--- /dev/null
+++ b/website/source/intro/index.html.markdown
@@ -0,0 +1,75 @@
+---
+layout: "intro"
+page_title: "Introduction"
+sidebar_current: "what"
+description: |-
+  Welcome to the intro guide to Vault! This guide is the best place to start with Vault. We cover what Vault is, what problems it can solve, how it compares to existing software, and contains a quick start for using Vault.
+---
+
+# Introduction to Vault
+
+Welcome to the intro guide to Vault! This guide is the best
+place to start with Vault. We cover what Vault is, what
+problems it can solve, how it compares to existing software,
+and contains a quick start for using Vault.
+
+If you are already familiar with the basics of Vault, the
+[documentation](/docs/index.html) provides a better reference
+guide for all available features as well as internals.
+
+## What is Vault?
+
+Vault is a tool for securely accessing _secrets_. A secret is anything
+that you want to tightly control access to, such as API keys, passwords,
+certificates, and more. Vault provides a unified interface to any
+secret, while providing tight access control and recording a detailed
+audit log.
+
+A modern system requires access to a multitude of secrets: database
+credentials, API keys for external services, credentials for
+service-oriented architecture communication, etc. Understanding who is
+accessing what secrets is already very difficult and platform-specific.
+Adding on key rolling, secure storage, and detailed audit logs is almost
+impossible without a custom solution. This is where Vault steps in.
+
+Examples work best to showcase Vault. Please see the
+[use cases](/intro/use-cases.html).
+
+The key features of Vault are:
+
+* **Secure Secret Storage**: Arbitrary key/value secrets can be stored
+  in Vault. Vault encrypts these secrets prior to writing them to persistent
+  storage, so gaining access to the raw storage isn't enough to access
+  your secrets. Vault can write to disk, [Consul](http://www.consul.io),
+  and more.
+
+* **Dynamic Secrets**: Vault can generate secrets on-demand for some
+  systems, such as AWS or SQL databases. For example, when an application
+  needs to access an S3 bucket, it asks Vault for credentials, and Vault
+  will generate an AWS keypair with valid permissions on demand. After
+  creating these dynamic secrets, Vault will also automatically revoke them
+  after the lease is up.
+
+* **Data Encryption**: Vault can encrypt and decrypt data without storing
+  it. This allows security teams to define encryption parameters and
+  developers to store encrypted data in a location such as SQL without
+  having to design their own encryption methods.
+
+* **Leasing and Renewal**: All secrets in Vault have a _lease_ associated
+  with it. At the end of the lease, Vault will automatically revoke that
+  secret. Clients are able to renew leases via built-in renew APIs.
+
+* **Revocation**: Vault has built-in support for secret revocation. Vault
+  can revoke not only single secrets, but a tree of secrets, for example
+  all secrets read by a specific user, or all secrets of a particular type.
+  Revocation assists in key rolling as well as locking down systems in the
+  case of an intrusion.
+
+## Next Steps
+
+See the page on [Vault use cases](/intro/use-cases.html) to see the
+multiple ways Vault can be used. Then see
+[how Vault compares to other software](/intro/vs/index.html)
+to see how it fits into your existing infrastructure. Finally, continue onwards with
+the [getting started guide](/intro/getting-started/install.html) to use
+Vault to read, write, and create real secrets and see how it works in practice.
diff --git a/website/source/intro/use-cases.html.markdown b/website/source/intro/use-cases.html.markdown
new file mode 100644
index 000000000..4f9df2381
--- /dev/null
+++ b/website/source/intro/use-cases.html.markdown
@@ -0,0 +1,55 @@
+---
+layout: "intro"
+page_title: "Use Cases"
+sidebar_current: "use-cases"
+description: |-
+  This page lists some concrete use cases for Vault, but the possible use cases are much broader than what we cover.
+---
+
+# Use Cases
+
+Before understanding use cases, it's useful to know [what Vault is](/intro/index.html).
+This page lists some concrete use cases for Vault, but the possible use cases are
+much broader than what we cover.
+
+#### General Secret Storage
+
+At a bare minimum, Vault can be used for the storage of any secrets. For
+example, Vault would be a fantastic way to store sensitive environment variables,
+database credentials, API keys, etc.
+
+Compare this with the current way to store these which might be
+plaintext in files, configuration management, a database, etc. It would be
+much safer to query these using `vault read` or the API. This protects
+the plaintext version of these secrets as well as records access in the Vault
+audit log.
+
+#### Employee Credential Storage
+
+While this overlaps with "General Secret Storage", Vault is a good mechanism
+for storing credentials that employees share to access web services. The
+audit log mechanism lets you know what secrets an employee accessed and
+when an employee leaves, it is easier to roll keys and understand which keys
+have and haven't been rolled.
+
+#### API Key Generation for Scripts
+
+The "dynamic secrets" feature of Vault is ideal for scripts: an AWS
+access key can be generated for the duration of a script, then revoked.
+The keypair will not exist before or after the script runs, and the
+creation of the keys are completely logged.
+
+This is an improvement over using something like Amazon IAM but still
+effectively hardcoding limited-access access tokens in various places.
+
+#### Data Encryption
+
+In addition to being able to store secrets, Vault can be used to
+encrypt/decrypt data that is stored elsewhere. The primary use of this is
+to allow applications to encrypt their data while still storing it in the
+primary data store.
+
+The benefit of this is that developers do not need to worry about how to
+properly encrypt data. The responsibility of encryption is on Vault
+and the security team managing it, and developers just encrypt/decrypt
+data as needed.
diff --git a/website/source/intro/vs/chef-puppet-etc.html.md b/website/source/intro/vs/chef-puppet-etc.html.md
new file mode 100644
index 000000000..6555d8ba4
--- /dev/null
+++ b/website/source/intro/vs/chef-puppet-etc.html.md
@@ -0,0 +1,45 @@
+---
+layout: "intro"
+page_title: "Vault vs. Chef, Puppet, etc."
+sidebar_current: "vs-other-chef"
+description: |-
+  Comparison between Vault and configuration management solutions such as Chef, Puppet, etc.
+---
+
+# Vault vs. Chef, Puppet, etc.
+
+A big part of configuring software is setting up secrets: configuring a
+web application to talk to a service, configuring the credentials of a
+database, etc. Because of this, configuration management systems all face
+a problem of safely storing these secrets.
+
+Chef, Puppet, etc. all solve this in a similar way: single-key
+encrypted storage. Chef has encrypted data bags, Puppet has encrypted
+Hiera, and so on. The encrypted data is always one secret (a password,
+a key, etc.) away from being decrypted, and this secret is generally
+not well protected since in an elastic environment, every server needs
+to somehow get this secret to decrypt the data. Additionally, access to
+the encrypted data isn't always logged, so if there is an intrusion, it
+isn't clear what data has been accessed and by who.
+
+Vault is not tied to any specific configuration management system. You can
+read secrets from configuration management, but you can also use the API
+directly to read secrets from applications. This means that configuration
+management requires less secrets, and in many cases doesn't ever have to
+persist them to disk.
+
+Vault encrypts the data onto physical storage and requires multiple
+keys to even read it. If an attacker were to gain access to the physical
+encrypted storage, it couldn't be read without multiple keys which are generally
+distributed to multiple individuals. This is known as _unsealing_, and happens
+once whenever Vault starts.
+
+For an unsealed Vault, every interaction is logged in via the audit backends.
+Even erroneous requests (invalid access tokens, for example) are logged.
+To access any data, an access token is required. This token is usually
+associated with an identity coming from a system such as GitHub, LDAP, etc.
+This identity is also written to the audit log.
+
+Access tokens can be given fine-grained control over what secrets can be
+accessed. It is rare to have a single key that can access all secrets. This
+makes it easier to have fine-grained access for consumers of Vault.
diff --git a/website/source/intro/vs/consul.html.md b/website/source/intro/vs/consul.html.md
new file mode 100644
index 000000000..3754455a0
--- /dev/null
+++ b/website/source/intro/vs/consul.html.md
@@ -0,0 +1,32 @@
+---
+layout: "intro"
+page_title: "Vault vs. Consul"
+sidebar_current: "vs-other-consul"
+description: |-
+  Comparison between Vault and attempting to store secrets with Consul.
+---
+
+# Vault vs. Consul
+
+[Consul](https://consul.io) is system for service discovery, monitoring,
+and configuration that is distributed and highly available. Consul also
+supports an ACL system to restrict access to keys and service information.
+
+While Consul can be used to store secret information and gate access using
+ACLs, it is not designed for that purpose. As such, data is not encrypted
+in transit nor at rest, it does not have pluggable authentication mechanisms,
+and there is no per-request auditing mechanism.
+
+Vault is designed from the ground up as a secret management solution. As such,
+it protects secrets in transit and at rest. It provides multiple authentication
+and audit logging mechanisms. Dynamic secret generation allows Vault to avoid
+providing clients with root privileges to underlying systems and makes
+it possible to do key rolling and revocation.
+
+The strength of Consul is that it is fault tolerant and highly scalable.
+By using Consul as a backend to Vault, you get the best of both. Consul
+is used for durable storage of encrypted data at rest and provides coordination
+so that Vault can be highly available and fault tolerant. Vault provides
+the higher level policy management, secret leasing, audit logging, and automatic
+revocation.
+
diff --git a/website/source/intro/vs/custom.html.markdown b/website/source/intro/vs/custom.html.markdown
new file mode 100644
index 000000000..3d8015f4f
--- /dev/null
+++ b/website/source/intro/vs/custom.html.markdown
@@ -0,0 +1,28 @@
+---
+layout: "intro"
+page_title: "Vault vs. Custom Solutions"
+sidebar_current: "vs-other-custom"
+description: |-
+  Comparison between Vault and writing a custom solution.
+---
+
+# Vault vs. Custom Solutions
+
+Many organizations resort to custom solutions for storing secrets,
+whether that be Dropbox, encrypted disk images, encrypted SQL columns,
+etc.
+
+These systems require time and resources to build and maintain.
+Storing secrets is also an incredibly important piece of infrastructure
+that must be done correctly. This increases the pressure to maintain
+the internal systems.
+
+Vault is designed for secret storage. It provides a simple interface
+on top of a strong security model to meet your secret storage needs.
+
+Furthermore, Vault is an open source tool. This means that the tool is
+as good as the entire community working together to improve it. This
+isn't just features and bug fixes, but finding potential security holes.
+Additionally, since it is an open source, your own security teams can
+review and contribute to Vault and verify it meets your standards
+for security.
diff --git a/website/source/intro/vs/dropbox.html.md b/website/source/intro/vs/dropbox.html.md
new file mode 100644
index 000000000..f3089549b
--- /dev/null
+++ b/website/source/intro/vs/dropbox.html.md
@@ -0,0 +1,25 @@
+---
+layout: "intro"
+page_title: "Vault vs. Dropbox"
+sidebar_current: "vs-other-dropbox"
+description: |-
+  Comparison between Vault and attempting to store secrets with Dropbox.
+---
+
+# Vault vs. Dropbox
+
+It is an unfortunate truth that many organizations, big and small,
+often use Dropbox as a mechanism for storing secrets. It is so common
+that we've decided to make a special section for it instead of throwing
+it under the "custom solutions" header.
+
+Dropbox is not made for storing secrets. Even if you're using something
+such as an encrypted disk image within Dropbox, it is subpar versus a
+real secret storage server.
+
+A real secret management tool such as Vault has a stronger security
+model, integrates with many different authentication services, stores
+audit logs, can generate dynamic secrets, and more.
+
+And, due to `vault` CLI, using `vault` on a developer machine is
+simple!
diff --git a/website/source/intro/vs/hsm.html.md b/website/source/intro/vs/hsm.html.md
new file mode 100644
index 000000000..4aac1c5dd
--- /dev/null
+++ b/website/source/intro/vs/hsm.html.md
@@ -0,0 +1,39 @@
+---
+layout: "intro"
+page_title: "Vault vs. HSMs"
+sidebar_current: "vs-other-hsm"
+description: |-
+  Comparison between Vault and HSM systems.
+---
+
+# Vault vs. HSMs
+
+A [hardware security module (HSM)](http://en.wikipedia.org/wiki/Hardware_security_module)
+is a hardware device that is meant to secure various secrets. They generally
+have very strong security models and adhere to many compliance regulations.
+
+The primary issue with HSMs is that they are expensive and not very
+cloud friendly. Amazon provides CloudHSM, but the minimum price point to
+even begin using CloudHSM is in the thousands of US dollars.
+
+Once an HSM is up and running, configuring it is generally very tedious,
+and the "API" to request secrets is also difficult to use. Example: CloudHSM
+requires SSH and setting up various keypairs manually. It is difficult to
+automate.
+
+Vault **doesn't replace an HSM**. There are many benefits to an HSM if
+you can afford it. Instead, an HSM is a fantastic potential secret backend
+for Vault. This would allow Vault to access the HSM data via the Vault API,
+making it significantly easier to use an HSM, while also retaining all the
+audit logs. In fact, you'd have multiple audit logs: requests to Vault
+as well as to the HSM.
+
+Vault can also do many things that HSMs cannot currently do, such
+as generating _dynamic secrets_. Instead of storing AWS access keys directly
+within Vault, Vault can generate access keys according to a specific
+policy on the fly. Vault has the potential of doing this for any
+system through its mountable secret backend system.
+
+For most companies, an HSM is overkill, and Vault is enough. For companies
+that can afford an HSM, it can be used with Vault to get the best of both
+worlds.
diff --git a/website/source/intro/vs/index.html.markdown b/website/source/intro/vs/index.html.markdown
new file mode 100644
index 000000000..ce7fc0b41
--- /dev/null
+++ b/website/source/intro/vs/index.html.markdown
@@ -0,0 +1,22 @@
+---
+layout: "intro"
+page_title: "Vault vs. Other Software"
+sidebar_current: "vs-other"
+description: |-
+  Comparisons between Vault and other software that claim to store secrets in some capacity.
+---
+
+# Vault vs. Other Software
+
+There are a number of other options in the market currently that claim
+to store secrets in some capacity. This section compares Vault to these
+other software choices.
+
+Due to the bias of the comparisons being on the Vault website, we attempt
+to only use facts. If you find something that is invalid or out of date
+in the comparisons, please
+[open an issue](https://github.com/hashicorp/vault/issues) and we'll
+address it as soon as possible.
+
+Use the navigation on the left to read comparisons of Vault versus other
+systems.
diff --git a/website/source/intro/vs/keywhiz.html.md b/website/source/intro/vs/keywhiz.html.md
new file mode 100644
index 000000000..84fcf2e7f
--- /dev/null
+++ b/website/source/intro/vs/keywhiz.html.md
@@ -0,0 +1,46 @@
+---
+layout: "intro"
+page_title: "Vault vs. Keywhiz"
+sidebar_current: "vs-other-keywhiz"
+description: |-
+  Comparison between Vault and Keywhiz.
+---
+
+# Vault vs. Keywhiz
+
+Keywhiz is a secret management solution built by Square. Keywhiz
+has a client/server architecture based on a RESTful API. Clients of
+Keywhiz access secrets through the API by authenticating with a client
+certificate or cookie. To allow for flexible consumption of secrets by arbitrary
+software, clients may also make use of a FUSE filesystem to expose secrets
+as files on disk, and use Unix file permissions for access control.  Human
+operators may authenticate using a cookie-based authentication either via command
+line utilities or through a management web interface.
+
+Vault similarly is designed as a comprehensive secret management
+solution. The client interaction with Vault is flexible
+both for authentication and usage of secrets. Vault supports [mTLS
+authentication](/docs/auth/cert.html) along with many [other
+mechanisms](/docs/auth/index.html). The goal being to make it easy to
+authenticate as a machine for programmatic access and as a human for
+operator usage.
+
+Vault and Keywhiz expose secrets via an API. The Vault
+[ACL system](/docs/concepts/policies.html) is used
+to protect secrets and gate access, similarly to the
+Keywhiz ACL system.  With Vault, All auditing is done
+server side using [audit backends](/docs/audit/index.html).
+
+Keywhiz focuses on storage and distribution of secrets and supports
+rotation through secret versioning, which is possible in the Keywhiz UI and
+command-line utilities. Vault also supports dynamic secrets and generating credentials
+on-demand for fine-grained security controls, but adds first class support
+for non-repudiation. Key rotation is a first class concern for Keywhiz and Vault, so
+that no external systems need to be used.
+
+Lastly Vault forces a mandatory lease contract with clients. All secrets read
+from Vault have an associated lease which enables operators to audit key usage,
+perform key rolling, and ensure automatic revocation. Vault provides multiple
+revocation mechanisms to give operators a clear "break glass" procedure after
+a potential compromise.
+
diff --git a/website/source/intro/vs/kms.html.md b/website/source/intro/vs/kms.html.md
new file mode 100644
index 000000000..be3c4b15c
--- /dev/null
+++ b/website/source/intro/vs/kms.html.md
@@ -0,0 +1,40 @@
+---
+layout: "intro"
+page_title: "Vault vs. Amazon Key Management Service"
+sidebar_current: "vs-other-kms"
+description: |-
+  Comparison between Vault and Amazon Key Management Service.
+---
+
+# Vault vs. Amazon KMS
+
+Amazon Key Management Service (KMS) is a service provided in the AWS
+ecosystem for encryption key management. It is backed by Hardware Security
+Modules (HSM) for physical security.
+
+Vault and KMS differ in the scope of problems they are trying to solve.
+The KMS service is focused on securely storing encryption keys and supporting
+cryptographic operations (encrypt and decrypt) using those keys. It supports
+access controls and auditing as well.
+
+In contrast, Vault provides a comprehensive secret management solution.
+The [`transit` backend](/docs/secrets/transit/index.html)
+provides similar capabilities as the KMS service, allowing for encryption keys
+to be stored and cryptographic operations to be performed. However, Vault goes
+much futher than just key management.
+
+The flexible secret backends allow Vault to handle any type of secret data,
+including database credentials, API keys, PKI keys, and encryption keys.
+Vault also supports dynamic secrets, generating credentials on-demand for
+fine-grained security controls, auditing, and non-repudiation.
+
+Lastly Vault forces a mandatory lease contract with clients. All secrets read
+from Vault have an associated lease which enables operations to audit key usage,
+perform key rolling, and ensure automatic revocation. Vault provides multiple
+revocation mechansims to give operators a clear "break glass" procedure after
+a potential compromise.
+
+Vault is an open source tool that can be deployed to any environment,
+and does not require any special hardware. This makes it well suited for cloud
+environments where HSMs are not available or are cost prohibitive.
+
diff --git a/website/source/layouts/_footer.erb b/website/source/layouts/_footer.erb
new file mode 100644
index 000000000..a9e43a607
--- /dev/null
+++ b/website/source/layouts/_footer.erb
@@ -0,0 +1,54 @@
+	<div id="footer">
+		<div class="container">
+			<div class="row">
+				<div class="col-sm-6 col-xs-12">
+					<ul class="footer-links nav navbar-nav">
+						<li class="li-under"><a href="/intro/index.html">Intro</a></li>
+						<li class="li-under"><a href="/docs/index.html">Docs</a></li>
+						<li class="li-under"><a href="/community.html">Community</a></li>
+						<li class="li-under"><a href="/security.html">Security</a></li>
+					</ul>
+				</div>
+				<div class="footer-hashi col-sm-6 col-xs-12">
+					<div class="pull-right">
+						<span>A <a href="https://www.hashicorp.com">HashiCorp</a> Project.</span>
+						<a class="hashi-logo" href="https://www.hashicorp.com"><i class="hashi-logo"></i></a>
+					</div>
+				</div>
+			</div>
+		</div>
+	</div>
+</div>
+
+<script>
+  (function(i,s,o,g,r,a,m){i['GoogleAnalyticsObject']=r;i[r]=i[r]||function(){
+  (i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new Date();a=s.createElement(o),
+  m=s.getElementsByTagName(o)[0];a.async=1;a.src=g;m.parentNode.insertBefore(a,m)
+  })(window,document,'script','//www.google-analytics.com/analytics.js','ga');
+
+  ga('create', 'UA-62364009-1', 'auto');
+  ga('send', 'pageview');
+</script>
+
+<script type="text/javascript">
+adroll_adv_id = "6QAAFJDIWBG3DJBDRJ7BEX";
+adroll_pix_id = "PYT5HSNKNRDS7LMUR5B6YG";
+(function () {
+var oldonload = window.onload;
+window.onload = function(){
+   __adroll_loaded=true;
+   var scr = document.createElement("script");
+   var host = (("https:" == document.location.protocol) ? "https://s.adroll.com" : "http://a.adroll.com");
+   scr.setAttribute('async', 'true');
+   scr.type = "text/javascript";
+   scr.src = host + "/j/roundtrip.js";
+   ((document.getElementsByTagName('head') || [null])[0] ||
+    document.getElementsByTagName('script')[0].parentNode).appendChild(scr);
+   if(oldonload){oldonload()}};
+}());
+</script>
+
+<%= javascript_include_tag "application" %>
+
+</body>
+</html>
diff --git a/website/source/layouts/_header.erb b/website/source/layouts/_header.erb
new file mode 100644
index 000000000..2d4cb352f
--- /dev/null
+++ b/website/source/layouts/_header.erb
@@ -0,0 +1,32 @@
+<div id="header" class="<%= current_page.data.page_title == "home" ? "" : "navbar-static-top" %>">
+	<div class="container">
+        <div class="row">
+            <div class="col-xs-12">
+                <div class="navbar-header">
+                    <div class="navbar-brand">
+                         <a class="logo" href="/">Nomad</a>
+                    </div>
+                    <ul class="main-links nav navbar-nav navbar-right hidden-xs">
+                        <li class="first li-under"><a href="/intro/index.html">Intro</a></li>
+                        <li class="li-under"><a href="/docs/index.html">Docs</a></li>
+                        <li class="li-under"><a href="/community.html">Community</a></li>
+                    </ul>
+                    <button class="navbar-toggle" type="button">
+                       <span class="sr-only">Toggle navigation</span>
+                       <span class="icon-bar"></span>
+                       <span class="icon-bar"></span>
+                       <span class="icon-bar"></span>
+                    </button>
+                </div>
+                <div class="buttons hidden-xs">
+	            		<nav role="navigation">
+	            			<ul class="nav navbar-nav navbar-right">
+	            				<li class="first download"><a href="/downloads.html">Download</a></li>
+	            				<li class="github"><a href="https://github.com/hashicorp/vault">GitHub</a></li>
+	            			</ul>
+	            		</nav>
+                </div>
+            </div>
+        </div>
+    </div>
+</div>
diff --git a/website/source/layouts/_meta.erb b/website/source/layouts/_meta.erb
new file mode 100644
index 000000000..283afb661
--- /dev/null
+++ b/website/source/layouts/_meta.erb
@@ -0,0 +1,21 @@
+<!DOCTYPE html>
+<html lang="en">
+  <head>
+    <meta charset="utf-8">
+    <meta name="viewport" content="width=device-width, initial-scale=1.0">
+    <meta name="description" content="<%= current_page.data.description %>">
+
+    <link rel="shortcut icon" href="<%= image_path('favicon.png') %>">
+
+    <title><%= [current_page.data.page_title, "Vault by HashiCorp"].compact.join(" - ") %></title>
+
+    <%= stylesheet_link_tag "application" %>
+
+    <!--[if lt IE 9]>
+      <%= javascript_include_tag "html5shiv", "respond.min" %>
+    <![endif]-->
+
+    <%= yield_content :head %>
+  </head>
+
+  <body id="page-<%= current_page.data.page_title ? "#{current_page.data.page_title}" : "home" %>" class="page-<%= current_page.data.page_title ? "#{current_page.data.page_title} layout-#{current_page.data.layout} page-sub" : "home layout-#{current_page.data.layout}" %>">
diff --git a/website/source/layouts/_sidebar.erb b/website/source/layouts/_sidebar.erb
new file mode 100644
index 000000000..f87359090
--- /dev/null
+++ b/website/source/layouts/_sidebar.erb
@@ -0,0 +1,26 @@
+<!-- Overlay for fixed sidebar -->
+<div class="sidebar-overlay"></div>
+
+<!-- Material sidebar -->
+<aside id="sidebar" class="sidebar sidebar-default sidebar-fixed-right" role="navigation">
+    <!-- Sidebar header -->
+    <div class="sidebar-header header-cover">
+        <!-- Sidebar brand image -->
+        <div class="sidebar-image">
+            <img src="<%= image_path('logo-header@2x.png') %>" width="49px" height="56px">
+        </div>
+    </div>
+
+    <!-- Sidebar navigation -->
+    <ul class="nav sidebar-nav">
+        <li class="first"><a href="/intro/index.html">Intro</a></li>
+        <li class=""><a href="/docs/index.html">Docs</a></li>
+        <li class=""><a href="/community.html">Community</a></li>
+    </ul>
+
+    <!-- Sidebar navigation 2-->
+    <ul class="buttons-nav">
+        <li class="first"><a class="v-btn gray sml" href="/downloads.html">Download</a></li>
+        <li class=""><a class="v-btn gray sml" href="https://github.com/hashicorp/vault">GitHub</a></li>
+    </ul>
+</aside>
diff --git a/website/source/layouts/docs.erb b/website/source/layouts/docs.erb
new file mode 100644
index 000000000..62c7c6428
--- /dev/null
+++ b/website/source/layouts/docs.erb
@@ -0,0 +1,193 @@
+<% wrap_layout :inner do %>
+	<% content_for :sidebar do %>
+		<div class="docs-sidebar hidden-print affix-top" role="complementary">
+			<ul class="nav docs-sidenav">
+				<li<%= sidebar_current("docs-home") %>>
+					<a href="/docs/index.html">Documentation Home</a>
+				</li>
+
+				<li<%= sidebar_current("docs-internal") %>>
+					<a href="/docs/internals/index.html">Internals</a>
+					<ul class="nav">
+						<li<%= sidebar_current("docs-internals-architecture") %>>
+							<a href="/docs/internals/architecture.html">Architecture</a>
+                        </li>
+
+						<li<%= sidebar_current("docs-internals-ha") %>>
+							<a href="/docs/internals/high-availability.html">High Availability</a>
+						</li>
+
+						<li<%= sidebar_current("docs-internals-security") %>>
+							<a href="/docs/internals/security.html">Security Model</a>
+                        </li>
+
+						<li<%= sidebar_current("docs-internals-telemetry") %>>
+							<a href="/docs/internals/telemetry.html">Telemetry</a>
+                        </li>
+
+						<li<%= sidebar_current("docs-internals-token") %>>
+							<a href="/docs/internals/token.html">Token Authentication</a>
+                        </li>
+
+						<li<%= sidebar_current("docs-internals-rotation") %>>
+							<a href="/docs/internals/rotation.html">Key Rotation</a>
+						</li>
+					</ul>
+				</li>
+
+				<li<%= sidebar_current("docs-install") %>>
+					<a href="/docs/install/index.html">Installation</a>
+				</li>
+
+				<li<%= sidebar_current("docs-concepts") %>>
+					<a href="/docs/concepts/index.html">Basic Concepts</a>
+					<ul class="nav">
+						<li<%= sidebar_current("docs-concepts-devserver") %>>
+							<a href="/docs/concepts/dev-server.html">"Dev" Server</a>
+						</li>
+
+						<li<%= sidebar_current("docs-concepts-seal") %>>
+							<a href="/docs/concepts/seal.html">Seal/Unseal</a>
+						</li>
+
+						<li<%= sidebar_current("docs-concepts-lease") %>>
+							<a href="/docs/concepts/lease.html">Lease, Renew, and Revoke</a>
+						</li>
+
+						<li<%= sidebar_current("docs-concepts-auth") %>>
+							<a href="/docs/concepts/auth.html">Authentication</a>
+						</li>
+
+						<li<%= sidebar_current("docs-concepts-tokens") %>>
+							<a href="/docs/concepts/tokens.html">Tokens</a>
+						</li>
+
+						<li<%= sidebar_current("docs-concepts-policies") %>>
+							<a href="/docs/concepts/policies.html">Access Control Policies</a>
+						</li>
+
+						<li<%= sidebar_current("docs-concepts-ha") %>>
+							<a href="/docs/concepts/ha.html">High Availability</a>
+						</li>
+					</ul>
+				</li>
+
+				<li<%= sidebar_current("docs-config") %>>
+					<a href="/docs/config/index.html">Configuration</a>
+				</li>
+
+				<li<%= sidebar_current("docs-commands") %>>
+					<a href="/docs/commands/index.html">Commands (CLI)</a>
+					<ul class="nav">
+						<li<%= sidebar_current("docs-commands-path-help") %>>
+							<a href="/docs/commands/help.html">Path Help</a>
+						</li>
+
+						<li<%= sidebar_current("docs-commands-readwrite") %>>
+							<a href="/docs/commands/read-write.html">Reading and Writing Data</a>
+						</li>
+					</ul>
+				</li>
+
+				<li<%= sidebar_current("docs-http") %>>
+					<a href="/docs/http/index.html">HTTP API</a>
+				</li>
+
+				<hr>
+
+				<li<%= sidebar_current("docs-secrets") %>>
+					<a href="/docs/secrets/index.html">Secret Backends</a>
+					<ul class="nav">
+						<li<%= sidebar_current("docs-secrets-aws") %>>
+							<a href="/docs/secrets/aws/index.html">AWS</a>
+						</li>
+
+						<li<%= sidebar_current("docs-secrets-consul") %>>
+							<a href="/docs/secrets/consul/index.html">Consul</a>
+						</li>
+
+						<li<%= sidebar_current("docs-secrets-pki") %>>
+							<a href="/docs/secrets/pki/index.html">PKI (Certificates)</a>
+                        </li>
+
+						<li<%= sidebar_current("docs-secrets-postgresql") %>>
+							<a href="/docs/secrets/postgresql/index.html">PostgreSQL</a>
+                        </li>
+
+						<li<%= sidebar_current("docs-secrets-mysql") %>>
+							<a href="/docs/secrets/mysql/index.html">MySQL</a>
+						</li>
+
+						<li<%= sidebar_current("docs-secrets-cassandra") %>>
+							<a href="/docs/secrets/cassandra/index.html">Cassandra</a>
+						</li>
+
+						<li<%= sidebar_current("docs-secrets-ssh") %>>
+							<a href="/docs/secrets/ssh/index.html">SSH</a>
+						</li>
+
+						<li<%= sidebar_current("docs-secrets-transit") %>>
+							<a href="/docs/secrets/transit/index.html">Transit</a>
+						</li>
+
+						<li<%= sidebar_current("docs-secrets-generic") %>>
+							<a href="/docs/secrets/generic/index.html">Generic</a>
+						</li>
+
+						<li<%= sidebar_current("docs-secrets-custom") %>>
+							<a href="/docs/secrets/custom.html">Custom</a>
+						</li>
+					</ul>
+				</li>
+
+				<li<%= sidebar_current("docs-auth") %>>
+					<a href="/docs/auth/index.html">Auth Backends</a>
+					<ul class="nav">
+						<li<%= sidebar_current("docs-auth-token") %>>
+                            <a href="/docs/auth/token.html">Tokens</a>
+						</li>
+
+						<li<%= sidebar_current("docs-auth-github") %>>
+							<a href="/docs/auth/github.html">GitHub</a>
+						</li>
+
+						<li<%= sidebar_current("docs-auth-appid") %>>
+							<a href="/docs/auth/app-id.html">App ID</a>
+						</li>
+
+						<li<%= sidebar_current("docs-auth-userpass") %>>
+							<a href="/docs/auth/userpass.html">Username &amp; Password</a>
+                        </li>
+
+						<li<%= sidebar_current("docs-auth-cert") %>>
+							<a href="/docs/auth/cert.html">TLS Certificates</a>
+                        </li>
+
+						<li<%= sidebar_current("docs-auth-ldap") %>>
+							<a href="/docs/auth/ldap.html">LDAP</a>
+						</li>
+
+						<li<%= sidebar_current("docs-auth-mfa") %>>
+							<a href="/docs/auth/mfa.html">MFA</a>
+						</li>
+					</ul>
+				</li>
+
+				<li<%= sidebar_current("docs-audit") %>>
+					<a href="/docs/audit/index.html">Audit Backends</a>
+					<ul class="nav">
+						<li<%= sidebar_current("docs-audit-file") %>>
+							<a href="/docs/audit/file.html">File</a>
+                        </li>
+
+						<li<%= sidebar_current("docs-audit-syslog") %>>
+							<a href="/docs/audit/syslog.html">Syslog</a>
+						</li>
+					</ul>
+				</li>
+			</ul>
+		</div>
+	<% end %>
+
+	<%= yield %>
+<% end %>
diff --git a/website/source/layouts/downloads.erb b/website/source/layouts/downloads.erb
new file mode 100644
index 000000000..653969e58
--- /dev/null
+++ b/website/source/layouts/downloads.erb
@@ -0,0 +1,17 @@
+<% wrap_layout :inner do %>
+	<% content_for :sidebar do %>
+		<div class="docs-sidebar hidden-print affix-top" role="complementary">
+			<ul class="nav docs-sidenav">
+				<li<%= sidebar_current("downloads-vault") %>>
+				<a href="/downloads.html">Download Vault</a>
+				</li>
+
+				<li>
+					<a href="/docs/install/index.html">Build from Source</a>
+				</li>
+			</ul>
+		</div>
+	<% end %>
+
+	<%= yield %>
+	<% end %>
diff --git a/website/source/layouts/http.erb b/website/source/layouts/http.erb
new file mode 100644
index 000000000..627b2aa35
--- /dev/null
+++ b/website/source/layouts/http.erb
@@ -0,0 +1,156 @@
+<% wrap_layout :inner do %>
+	<% content_for :sidebar do %>
+		<div class="docs-sidebar hidden-print affix-top" role="complementary">
+			<ul class="nav docs-sidenav">
+				<li<%= sidebar_current("docs-home") %>>
+					<a href="/docs/index.html">Documentation Home</a>
+				</li>
+
+				<hr>
+
+				<li<%= sidebar_current("docs-http-overview") %>>
+					<a href="/docs/http/index.html">Overview</a>
+				</li>
+
+				<li<%= sidebar_current("docs-http-libraries") %>>
+					<a href="/docs/http/libraries.html">Libraries</a>
+				</li>
+
+				<li<%= sidebar_current("docs-http-sys-init") %>>
+					<a href="#">Initialization</a>
+					<ul class="nav nav-visible">
+						<li<%= sidebar_current("docs-http-sys-init") %>>
+							<a href="/docs/http/sys-init.html">/sys/init</a>
+						</li>
+					</ul>
+				</li>
+
+				<li<%= sidebar_current("docs-http-seal") %>>
+					<a href="#">Seal/Unseal</a>
+					<ul class="nav nav-visible">
+						<li<%= sidebar_current("docs-http-seal-status") %>>
+							<a href="/docs/http/sys-seal-status.html">/sys/seal-status</a>
+						</li>
+
+						<li<%= sidebar_current("docs-http-seal-seal") %>>
+							<a href="/docs/http/sys-seal.html">/sys/seal</a>
+						</li>
+
+						<li<%= sidebar_current("docs-http-seal-unseal") %>>
+							<a href="/docs/http/sys-unseal.html">/sys/unseal</a>
+						</li>
+					</ul>
+				</li>
+
+				<li<%= sidebar_current("docs-http-mounts") %>>
+					<a href="#">Secret Mounts</a>
+					<ul class="nav nav-visible">
+						<li<%= sidebar_current("docs-http-mounts-mounts") %>>
+							<a href="/docs/http/sys-mounts.html">/sys/mounts</a>
+						</li>
+
+						<li<%= sidebar_current("docs-http-mounts-remount") %>>
+							<a href="/docs/http/sys-remount.html">/sys/remount</a>
+						</li>
+					</ul>
+				</li>
+
+				<li<%= sidebar_current("docs-http-auth") %>>
+					<a href="#">Auth & ACLs</a>
+					<ul class="nav nav-visible">
+						<li<%= sidebar_current("docs-http-auth-auth") %>>
+							<a href="/docs/http/sys-auth.html">/sys/auth</a>
+						</li>
+
+						<li<%= sidebar_current("docs-http-auth-policy") %>>
+							<a href="/docs/http/sys-policy.html">/sys/policy</a>
+						</li>
+					</ul>
+				</li>
+
+				<li<%= sidebar_current("docs-http-audits") %>>
+					<a href="#">Audit Backends</a>
+					<ul class="nav nav-visible">
+						<li<%= sidebar_current("docs-http-audits-audits") %>>
+							<a href="/docs/http/sys-audit.html">/sys/audit</a>
+						</li>
+					</ul>
+				</li>
+
+				<li<%= sidebar_current("docs-http-lease") %>>
+					<a href="#">Leases</a>
+					<ul class="nav nav-visible">
+						<li<%= sidebar_current("docs-http-lease-renew") %>>
+							<a href="/docs/http/sys-renew.html">/sys/renew</a>
+						</li>
+
+						<li<%= sidebar_current("docs-http-lease-revoke-single") %>>
+							<a href="/docs/http/sys-revoke.html">/sys/revoke</a>
+                        </li>
+
+						<li<%= sidebar_current("docs-http-lease-revoke-prefix") %>>
+							<a href="/docs/http/sys-revoke-prefix.html">/sys/revoke-prefix</a>
+						</li>
+					</ul>
+                </li>
+
+                <li<%= sidebar_current("docs-http-ha") %>>
+					<a href="#">High Availability</a>
+					<ul class="nav nav-visible">
+						<li<%= sidebar_current("docs-http-ha-leader") %>>
+							<a href="/docs/http/sys-leader.html">/sys/leader</a>
+						</li>
+					</ul>
+                </li>
+
+                <li<%= sidebar_current("docs-http-rotate") %>>
+					<a href="#">Key Rotation</a>
+					<ul class="nav nav-visible">
+						<li<%= sidebar_current("docs-http-rotate-key-status") %>>
+							<a href="/docs/http/sys-key-status.html">/sys/key-status</a>
+                        </li>
+
+						<li<%= sidebar_current("docs-http-rotate-rekey") %>>
+							<a href="/docs/http/sys-rekey.html">/sys/rekey/</a>
+                        </li>
+
+						<li<%= sidebar_current("docs-http-rotate-rotate") %>>
+							<a href="/docs/http/sys-rotate.html">/sys/rotate</a>
+						</li>
+					</ul>
+                </li>
+
+                <li<%= sidebar_current("docs-http-debug") %>>
+					<a href="#">Debug</a>
+					<ul class="nav nav-visible">
+						<li<%= sidebar_current("docs-http-debug-raw") %>>
+							<a href="/docs/http/sys-raw.html">/sys/raw</a>
+                        </li>
+
+						<li<%= sidebar_current("docs-http-debug-health") %>>
+							<a href="/docs/http/sys-health.html">/sys/health</a>
+						</li>
+					</ul>
+                </li>
+
+                <hr>
+
+				<li<%= sidebar_current("docs-http-secret") %>>
+					<a href="/docs/secrets/index.html">Secret Backends</a>
+				</li>
+
+				<li<%= sidebar_current("docs-http-authbackends") %>>
+					<a href="/docs/auth/index.html">Auth Backends</a>
+                </li>
+
+				<li<%= sidebar_current("docs-http-auditbackends") %>>
+					<a href="/docs/audit/index.html">Audit Backends</a>
+				</li>
+			</ul>
+		</div>
+	<% end %>
+
+	<div class="bs-api-section">
+	<%= yield %>
+	</div>
+<% end %>
diff --git a/website/source/layouts/inner.erb b/website/source/layouts/inner.erb
new file mode 100644
index 000000000..aa8d62cc5
--- /dev/null
+++ b/website/source/layouts/inner.erb
@@ -0,0 +1,14 @@
+<% wrap_layout :layout do %>
+<div class="container">
+	<div class="row">
+		<div class="col-md-offset-1 col-md-2 col-sm-3 col-xs-12">
+			<%= yield_content :sidebar %>
+		</div>  <!-- /col-md-4 -->
+		<div id="main-content" class="col-sm-9 col-md-8 col-xs-12" role="main">
+			<div class="bs-docs-section">
+				<%= yield %>
+			</div>
+		</div>
+	</div>
+</div>
+<% end %>
diff --git a/website/source/layouts/intro.erb b/website/source/layouts/intro.erb
new file mode 100644
index 000000000..8ff9347fa
--- /dev/null
+++ b/website/source/layouts/intro.erb
@@ -0,0 +1,99 @@
+<% wrap_layout :inner do %>
+	<% content_for :sidebar do %>
+		<div class="docs-sidebar hidden-print affix-top" role="complementary">
+			<ul class="nav docs-sidenav">
+				<li<%= sidebar_current("what") %>>
+					<a href="/intro/index.html">What is Vault?</a>
+				</li>
+
+				<li<%= sidebar_current("use-cases") %>>
+					<a href="/intro/use-cases.html">Use Cases</a>
+				</li>
+
+				<li<%= sidebar_current("vs-other") %>>
+					<a href="/intro/vs/index.html">Vault vs. Other Software</a>
+					<ul class="nav">
+						<li<%= sidebar_current("vs-other-chef") %>>
+							<a href="/intro/vs/chef-puppet-etc.html">Chef, Puppet, etc.</a>
+						</li>
+
+						<li<%= sidebar_current("vs-other-hsm") %>>
+							<a href="/intro/vs/hsm.html">HSMs</a>
+						</li>
+
+						<li<%= sidebar_current("vs-other-dropbox") %>>
+							<a href="/intro/vs/dropbox.html">Dropbox</a>
+                        </li>
+
+						<li<%= sidebar_current("vs-other-consul") %>>
+							<a href="/intro/vs/consul.html">Consul</a>
+                        </li>
+
+						<li<%= sidebar_current("vs-other-kms") %>>
+							<a href="/intro/vs/kms.html">Amazon KMS</a>
+                        </li>
+
+						<li<%= sidebar_current("vs-other-keywhiz") %>>
+							<a href="/intro/vs/keywhiz.html">Keywhiz</a>
+						</li>
+
+						<li<%= sidebar_current("vs-other-custom") %>>
+							<a href="/intro/vs/custom.html">Custom Solutions</a>
+						</li>
+					</ul>
+				</li>
+
+				<li<%= sidebar_current("gettingstarted") %>>
+					<a href="/intro/getting-started/install.html">Getting Started</a>
+					<ul class="nav">
+						<li<%= sidebar_current("gettingstarted-install") %>>
+							<a href="/intro/getting-started/install.html">Install Vault</a>
+						</li>
+
+						<li<%= sidebar_current("gettingstarted-devserver") %>>
+							<a href="/intro/getting-started/dev-server.html">Starting the Server</a>
+						</li>
+
+						<li<%= sidebar_current("gettingstarted-firstsecret") %>>
+							<a href="/intro/getting-started/first-secret.html">Your First Secret</a>
+						</li>
+
+						<li<%= sidebar_current("gettingstarted-secretbackends") %>>
+							<a href="/intro/getting-started/secret-backends.html">Secret Backends</a>
+						</li>
+
+						<li<%= sidebar_current("gettingstarted-dynamicsecrets") %>>
+							<a href="/intro/getting-started/dynamic-secrets.html">Dynamic Secrets</a>
+						</li>
+
+						<li<%= sidebar_current("gettingstarted-help") %>>
+							<a href="/intro/getting-started/help.html">Built-in Help</a>
+						</li>
+
+						<li<%= sidebar_current("gettingstarted-auth") %>>
+							<a href="/intro/getting-started/authentication.html">Authentication</a>
+						</li>
+
+						<li<%= sidebar_current("gettingstarted-acl") %>>
+							<a href="/intro/getting-started/acl.html">ACLs</a>
+						</li>
+
+						<li<%= sidebar_current("gettingstarted-deploy") %>>
+							<a href="/intro/getting-started/deploy.html">Deploy Vault</a>
+						</li>
+
+						<li<%= sidebar_current("getting-started-apis") %>>
+							<a href="/intro/getting-started/apis.html">HTTP API</a>
+						</li>
+
+						<li<%= sidebar_current("gettingstarted-nextsteps") %>>
+							<a href="/intro/getting-started/next-steps.html">Next Steps</a>
+						</li>
+					</ul>
+				</li>
+			</ul>
+		</div>
+	<% end %>
+
+	<%= yield %>
+<% end %>
diff --git a/website/source/layouts/layout.erb b/website/source/layouts/layout.erb
new file mode 100644
index 000000000..4bbec3397
--- /dev/null
+++ b/website/source/layouts/layout.erb
@@ -0,0 +1,7 @@
+<%= partial "layouts/meta" %>
+<%= partial "layouts/header" %>
+<%= partial "layouts/sidebar" %>
+
+<%= yield %>
+
+<%= partial "layouts/footer" %>
diff --git a/website/source/robots.txt b/website/source/robots.txt
new file mode 100644
index 000000000..190c6ce04
--- /dev/null
+++ b/website/source/robots.txt
@@ -0,0 +1,8 @@
+---
+layout: false
+noindex: true
+---
+
+User-agent: *
+Disallow: /404
+Disallow: /500
diff --git a/website/source/security.html.erb b/website/source/security.html.erb
new file mode 100644
index 000000000..aba12837d
--- /dev/null
+++ b/website/source/security.html.erb
@@ -0,0 +1,27 @@
+---
+layout: "inner"
+page_title: "Security"
+description: |-
+  Vault takes security very seriously. Please responsibly disclose any security vulnerabilities found and we'll handle it quickly.
+---
+
+<h1>Security</h1>
+
+<p>
+We understand that many users place a high level of trust in HashiCorp and
+the tools we build. We apply best practices and focus on security to make
+sure we can maintain the trust of the community.
+</p>
+<p>
+We deeply appreciate any effort to disclose vulnerabilities responsibly.
+</p>
+<p>
+If you would like to report a vulnerability, please see the
+<a href="https://www.hashicorp.com/security.html">HashiCorp security page</a>,
+which has the proper email to communicate with as well as our PGP key.
+</p>
+<p>
+If you aren't reporting a security sensitive vulnerability, please
+open an issue on the standard <a href="https://github.com/hashicorp/vault">GitHub</a>
+repository.
+</p>
diff --git a/website/source/sitemap.xml.builder b/website/source/sitemap.xml.builder
new file mode 100644
index 000000000..a08b5b0e3
--- /dev/null
+++ b/website/source/sitemap.xml.builder
@@ -0,0 +1,19 @@
+---
+layout: false
+---
+
+xml.instruct!
+xml.urlset 'xmlns' => "http://www.sitemaps.org/schemas/sitemap/0.9" do
+  sitemap
+    .resources
+    .select { |page| page.path =~ /\.html/ }
+    .select { |page| !page.data.noindex }
+    .each do |page|
+      xml.url do
+        xml.loc File.join(base_url, page.url)
+        xml.lastmod Date.today.to_time.iso8601
+        xml.changefreq page.data.changefreq || "monthly"
+        xml.priority page.data.priority || "0.5"
+      end
+  end
+end
diff --git a/website/version.txt b/website/version.txt
new file mode 100644
index 000000000..3143519fa
--- /dev/null
+++ b/website/version.txt
@@ -0,0 +1,3 @@
+Bump this to force website deploy:
+
+3