Update grouping-tagging.md

* Create export-static-html.md

* Update export-static-html.md

articles/billing/fair-billing-policy.md

@@ -0,0 +1,30 @@
+# Fair Billing Policy 
+
+We believe you should only have to pay for members that are actively using Stoplight, so we offer a Fair Billing Policy. We go a step beyond traditional Fair Billing Policies and only count a member as active if they have taken a meaninful action inside of Stoplight in the last 30 days. Feel free to invite users to your Stoplight organization, and rest assured that they will not count towards billing until they have found the time to really get started.
+
+## Overview
+
+- You’ll only be charged for members that are active on the day that you upgrade to a paid plan.
+- If all members become passive, you will be charged the minimum active member count for your chosen plan, unless you decide to downgrade to the Open Source plan.
+- Any changes to the number of active members will be reflected in your monthly statement.
+
+## Active Member
+
+To be considered an active member, you must perform one of the following actions in the last 30 days: 
+
+- Create or update a project
+- Create, update, or delete project files
+
+Any members that have not performed one of these actions in the last 30 days are considered passive members. 
+
+## Billing
+
+Every new member starts as a passive member. They will not count as an active member until they login/register and perform their first action.
+
+We’ll keep track of this for you, and bill you at the end of each month. We also automatically detect when members become passive (ie when they have not performed an action in 30 days). When that happens, we will deposit prorated credits to your Stoplight account that will be applied on your next invoice. These credits have no currency or exchange value, are non-transferable and non-refundable, and will expire following the termination of your paid services plan with Stoplight.
+
+---
+**Related Articles**
+- [Personal Plan Overview](/platform/getting-started/billing/plans-overview)
+- [Organization Plan Overview](/platform/getting-started/billing/organization-plan-overview)
+- [FAQs](/platform/getting-started/billing/faqs)

articles/billing/org-overview.md

@@ -1,6 +1,9 @@
 # Organization Plan Overview 
 
 ![Organization Billing Overview](https://github.com/stoplightio/docs/blob/develop/assets/images/org-billing.png?raw=true)
+
+> Organization Plans are attached to an Organization, not an account. Only the **Owner** of the Organization can modify the billing settings 
+
 ## Platform Plans 
 
 ### Open Source 
@@ -61,4 +64,9 @@
     - SAML single sign-on 
     - OAuth token generation 
 
+---
+**Related Articles**
+- [Fair Billing Policy](/platform/getting-started/billing/fair-billing)
+- [Personal Plan Overview](/platform/getting-started/billing/plans-overview)
+- [FAQs](/platform/getting-started/billing/faqs)
 

articles/billing/overview.md

@@ -1,43 +1,73 @@
-# Personal Billing Overview 
-
-![Billing Overview](https://github.com/stoplightio/docs/blob/develop/assets/images/billing.png?raw=true)
-
-## Platform Plans 
-
-### Open Source
-- Price: Free 
-- Features: 
-    - API Modeling 
-    - Documentation 
-    - Mocking
-    - Testing 
-
-### Developer 
-- Price: $9/month 
-- Features:
-    - Unlimited Private Projects 
-    - Coming Soon: Github Integration 
-
-## Documentation Plans 
-
-### Basic 
-- Price: Free 
-- Features: 
-    - Unlimited Visits 
-    - Publish to .docs.stoplight.io 
-    - Docs & OpenAPI Editors 
-
-### Essential 
-- Price: $79/month 
-- Features: 
-    - Publish to your Domain (1 domain)
-    - Theming 
-    - Build History & Instant Rollbacks 
-
-### Standard 
-- Price: $179/month 
-- Features:
-    - Publish to your Domain (10 domains)
-    - Custom CSS
-    - White Label 
-    - Basic Auth & Auth0 Integration 
+# Billing Overview 
+
+## Personal Billing 
+Personal Billing Plans are attached to your account. For more information, visit [the billing page](https://next.stoplight.io/pricing).
+
+## Organization Billing
+Organization Billing Plans are attached to an Organization, not an account. Only the Owner of the Organization can modify the billing settings. For more information, visit [the billing page](https://next.stoplight.io/pricing). 
+
+## Fair Use Billing Policy 
+
+We believe you should only have to pay for members that are actively using Stoplight, so we offer a Fair Billing Policy. We go a step beyond traditional Fair Billing Policies and only count a member as active if they have taken a meaninful action inside of Stoplight in the last 30 days. Feel free to invite users to your Stoplight organization, and rest assured that they will not count towards billing until they have found the time to really get started.
+
+### Overview
+
+- You’ll only be charged for members that are active on the day that you upgrade to a paid plan.
+- If all members become passive, you will be charged the minimum active member count for your chosen plan, unless you decide to downgrade to the Open Source plan.
+- Any changes to the number of active members will be reflected in your monthly statement.
+
+### Active Member
+
+To be considered an active member, you must perform one of the following actions in the last 30 days: 
+
+- Create or update a project
+- Create, update, or delete project files
+
+Any members that have not performed one of these actions in the last 30 days are considered passive members. 
+
+### Billing
+
+Every new member starts as a passive member. They will not count as an active member until they login/register and perform their first action.
+
+We’ll keep track of this for you, and bill you at the end of each month. We also automatically detect when members become passive (ie when they have not performed an action in 30 days). When that happens, we will deposit prorated credits to your Stoplight account that will be applied on your next invoice. These credits have no currency or exchange value, are non-transferable and non-refundable, and will expire following the termination of your paid services plan with Stoplight.
+
+## FAQs
+
+**Organizations: What counts as an active member?**
+
+A member is considered active if they have updated any projects or project files in the past 30 days. Otherwise, they are considered a passive member.
+
+**Will my billing automatically adjust as members change between passive and active?**
+
+Yes, we will automatically detect changes to member status and adjust your bill accordingly. Your account will receive prorated credits or charges as member status changes.
+
+**Is my credit card information secure?**
+
+Yes. All credit card processing is handled through Stripe, and your card information is never sent to, or stored on, our servers.
+
+**What kind of payments do you accept?**
+
+We accept all major credit cards including American Express, Discover, Mastercard, and Visa.
+
+**Is there a free trial?**
+
+Yes. Every new account / organization has 14 days to try out the platform.
+
+**When will I be charged?**
+
+After entering your card details, your card will be charged for the initial 30 day or annual billing cycle, depending on the interval chosen.
+
+**How do I cancel my account?**
+
+To cancel, send an email to support@stoplight.io and we will take care of the rest.
+
+**Can I buy a multi-year subscription?**
+
+Yes. Please send an email to support@stoplight.io for more info and we can quote a custom plan.
+
+**Do you have any discounts for open source, non-profits. or educational institutions?**
+
+Yes. Please send an email to support@stoplight.io for more info. To provide the discount, we will ask for more information based on the type of discount. 
+
+
+

articles/desktop/overview.md

@@ -1,7 +1,7 @@
 # Web & Desktop App
 
 
-Stoplight has a desktop app! Download the appropriate version [here](https://stoplight.io/download) .
+Stoplight has a desktop app! Download the appropriate version [here](https://github.com/stoplightio/desktop/releases/latest).
 
 
 ## Web or Local?

articles/editor/export-files.md

@@ -20,3 +20,13 @@ You can export any files in Stoplight to use as you see fit. Exported files are
 1. Select the **project** that contains the file you wish to export 
 2. Hover over the file you wish to export and click on the **right facing arrow**
 3. A new tab will open containing your exported file 
+
+---
+**Related Articles**
+- [Read, Design, & Code View](/platform/editor-basics/read-design-code-view)
+- [Working with Files](/platform/editor-basics/working-with-files)
+- [Import Files](/platform/editor-basics/import-files)
+- [Change History](/platform/editor-basics/change-history)
+- [Editor Configuration](/platform/editor-basics/editor-configuration)
+- [Environments](/platform/editor-basics/environments)
+- [File Validation](/platform/editor-basics/file-validation)

articles/editor/file-validation.md

@@ -22,4 +22,4 @@ Different types of file validations are used throughout the Stoplight platform.
 
 **Related Articles**
 
-* [Validating Your API Spec](/modeling/modeling-with-openapi/validating-your-api-sec)
+* [Validating Your API Spec](/modeling/modeling-with-openapi/validating-your-api-spec)

articles/editor/import-files.md

@@ -23,3 +23,13 @@ Copy and paste your markdown into Stoplight’s Modeling platform to add descrip
 1. Create a new file or choose an existing one 
 2. Select the **Design View**
 3. Copy and paste your Markdown into **Text Blocks** 
+
+---
+**Related Articles**
+- [Read, Design, & Code View](/platform/editor-basics/read-design-code-view)
+- [Working with Files](/platform/editor-basics/working-with-files)
+- [Export Files](/platform/editor-basics/export-files)
+- [Change History](/platform/editor-basics/change-history)
+- [Editor Configuration](/platform/editor-basics/editor-configuration)
+- [Environments](/platform/editor-basics/environments)
+- [File Validation](/platform/editor-basics/file-validation)

articles/enterprise/authentication/saml.md

@@ -0,0 +1,48 @@
+# Configuring SAML Authentication
+
+To configure Stoplight Enterprise to use SAML for user authentication,
+add the following variable to the Stoplight API
+configuration/environment:
+
+```bash
+SL_SSO_ENTRYPOINT="https://your-saml-server.example.com/..."
+```
+
+Where `SL_SSO_ENTRYPOINT` is the full URL to the SAML server providing
+the SAML assertions.
+
+Once set in the API configuration, restart the API:
+
+```bash
+# docker installs
+sudo docker restart stoplight-api
+
+# package installs
+sudo systemctl restart stoplight-api
+```
+
+Once restarted, all login requests will be authenticated via the
+external SAML service.
+
+> Please note, Stoplight's SAML integration does not currently use
+  SAML assertions for determining group/organization
+  membership. Group/organization membership should be managed through
+  the Stoplight application itself.
+
+## SAML IdP Metadata
+
+To configure Stoplight SAML integration from the SAML server, use the following SAML metadata file:
+
+```xml
+<EntityDescriptor xmlns="urn:oasis:names:tc:SAML:2.0:metadata" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" entityID="stoplight" ID="stoplight">
+<SPSSODescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
+<NameIDFormat>
+urn:oasis:names:tc:SAML:2.0:nameid-format:persistent
+</NameIDFormat>
+<AssertionConsumerService index="1" isDefault="true" Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://stoplight-api.internal.example.com/sso/global/saml/callback"/>
+</SPSSODescriptor>
+</EntityDescriptor>
+```
+
+Be sure to update the `AssertionConsumerService` / `Location` object
+with the correct callback URL for the Stoplight API.

articles/enterprise/components/api.md

@@ -0,0 +1,292 @@
+# The Stoplight API
+
+The **API** component powers the Stoplight backend, connecting the UI to the
+datastore and other miscellaneous Stoplight services.
+
+> #### Networking Details
+>
+> The default port for the API component is TCP port **3030**. The port can be
+> customized using the `PORT` configuration variable.
+>
+> The API must be able to receive incoming connections from the following components:
+>
+> * User Clients (web browser or desktop application)
+> * App
+>
+> The API must be able to make outgoing connections to the following components:
+>
+> * PostgreSQL
+> * Redis
+> * Gitlab
+> * Exporter
+> * Prism
+
+> #### Component Dependencies
+>
+> Make sure the following components are available **before** starting the API
+> service:
+>
+> * PostgreSQL
+> * Redis
+> * Gitlab
+
+## Installation
+
+The Stoplight API can be installed with Docker or RPM package.
+
+### RPM Package
+
+Prior to installing the RPM package, you will need to:
+
+* Install NodeJS
+
+* Have the Stoplight package repository installed and configured with your user-specific credentials
+
+#### Installing NodeJS
+
+To install NodeJS, run the following commands:
+
+```bash
+# make sure all current versions of nodejs are removed
+sudo yum remove nodejs npm -y
+
+# install nodejs
+sudo rpm -Uvh https://rpm.nodesource.com/pub_8.x/el/7/x86_64/nodejs-8.9.4-1nodesource.x86_64.rpm
+```
+
+Once the installation has completed, verify the version installed with the command:
+
+```bash
+$ node --version
+v8.9.4
+```
+
+If you do not see a version starting `v8.9`, contact Stoplight support for assistance.
+
+#### Setting up the Package Repository
+
+You can setup the Stoplight package repo by copying-and-pasting the contents
+below into a terminal:
+
+```bash
+# expose credentials to environment first
+REPO_USERNAME="myusername"
+REPO_PASSWORD="mypassword"
+
+# write credentials to repo file
+cat <<EOF | sudo tee /etc/yum.repos.d/stoplight.repo
+[stoplight]
+name=Stoplight Package Repository
+baseurl=https://$REPO_USERNAME:$REPO_PASSWORD@pkg.stoplight.io/rpm
+enabled=1
+gpgcheck=1
+repo_gpgcheck=1
+gpgkey=https://pkg.stoplight.io/stoplight.key
+EOF
+```
+
+> Make sure that the repository credentials are set before issuing the `cat` command above.
+
+#### Installing the API Package
+
+Once the repository is configured properly, you can install the API component
+using the command:
+
+```bash
+sudo yum install stoplight-api -y
+```
+
+### Docker
+
+To install the API component with Docker, run the command below:
+
+```bash
+docker pull quay.io/stoplight/api
+```
+
+> Note, if the system you are using has not already authenticated with the
+> Stoplight container registry, you will be prompted for credentials.
+
+## Configuration
+
+To configure the Stoplight API component, you will need to provide runtime
+values and connection details to the other necessary Stoplight components. The
+API can be configured either by the configuration file or through the
+environment.
+
+> The same configuration variables can be used regardless of installation type
+> (container or package-based).
+
+### Variables
+
+#### SIGN_SECRET
+
+The `SIGN_SECRET` variable is used to encrypt session cookies and other secrets
+used by the Stoplight API.
+
+```
+SIGN_SECRET="CHANGE_ME_TO_SOMETHING_RANDOM"
+```
+
+There is no minimum or maximum character requirement, however Stoplight
+recommends using a random string more than 32 characters in length for
+production environments.
+
+> Note that the `SIGN_SECRET` configuration variable must remain static between
+> service restarts
+
+#### POSTGRES_URL
+
+The `POSTGRES_URL` variable is the connection URI for the PostgreSQL database
+shared with Gitlab.
+
+```
+POSTGRES_URL="postgres://username:password@example.com:5432/database_name"
+```
+
+#### SL_COOKIE_DOMAIN
+
+The `SL_COOKIE_DOMAIN` variable is the name of the top-level domain that
+Stoplight is being served from.
+
+```
+SL_COOKIE_DOMAIN="example.com"
+```
+
+For example, if Stoplight is being served from the `stoplight.example.com`
+domain, set this variable to `example.com`.
+
+#### SL_APP_HOST
+
+The `SL_APP_HOST` variable is the full URL to the Stoplight app component.
+
+```
+SL_APP_HOST="http://localhost:3030"
+```
+
+#### SL_API_HOST
+
+The `SL_API_HOST` variable is the full URL to this (the Stoplight API) component.
+
+```
+SL_API_HOST="http://localhost:3030"
+```
+
+#### SL_EXPORTER_HOST
+
+The `SL_EXPORTER_HOST` variable is the full URL to the Stoplight exporter component.
+
+```
+SL_EXPORTER_HOST="http://localhost:3031"
+```
+
+#### SL_GITLAB_HOST
+
+The `SL_GITLAB_HOST` variable is the full URL to the Stoplight GitLab instances HTTP port.
+
+```
+SL_GITLAB_HOST="http://localhost:8080"
+```
+
+#### SL_REDIS_URL
+
+The `SL_REDIS_URL` variable is the full URL to a Redis instance.
+
+```
+SL_REDIS_URL="redis://:password@example.com:6379"
+```
+
+#### DISABLE_REGISTRATION
+
+The `DISABLE_REGISTRATION` variable can be used to prevent new users from
+registering with Stoplight. Enabling this feature does not prevent existing
+users from inviting new users.
+
+```
+DISABLE_REGISTRATION=false
+```
+
+If this option is set to `true`, new user registration requests will receive the
+following error when attempting to register:
+
+> User registration has been temporarily disabled. Please contact your administrator.
+
+### RPM Package
+
+The Stoplight API configuration file is located at the path:
+
+```bash
+/etc/stoplight-api/stoplight-api.cfg
+```
+
+Be sure to customize any variables as needed to match your environment
+**before** starting the API service.
+
+> Any changes to the API configuration requires a service restart in order to
+> take effect.
+
+### Docker
+
+To expose configuration variables to the Docker runtime, either write them to a
+file and use the `--env-file` argument:
+
+```bash
+cat <<EOF>api-env-vars
+SL_APP_HOST="..."
+...
+EOF
+
+docker run --env-file api-env-vars ...
+```
+
+Or you can expose them one at a time with the `-e` flag:
+
+```bash
+docker run -e SL_APP_HOST=https://stoplight.example.com ...
+```
+
+## Running
+
+### RPM Package
+
+To start the API server, run the command:
+
+```bash
+sudo systemctl start stoplight-api
+```
+
+Once started, you can see the status of the service using the command:
+
+```bash
+sudo systemctl status stoplight-api
+```
+
+### Docker
+
+To start the API container, run the command:
+
+```bash
+docker run \
+	--restart on-failure \
+	-p 3030:3030 \
+	quay.io/stoplight/api:latest
+```
+
+> Remember to set any necessary environment variables
+
+If started properly, the container should be marked with a healthy status after
+30 seconds. Use the `docker ps` command to verify the container was started and
+is running properly.
+
+## Post-install Validations
+
+Once the API component is running, you can verify the installation was
+successful issuing an `HTTP GET` request to the `/health` endpoint:
+
+```bash
+# remember to update the scheme, host, and port here to match your installation
+curl -v http://localhost:3030/health
+```
+
+If the API was installed and configured properly, you will receive an `HTTP 200`
+response back.

articles/enterprise/components/app.md

@@ -0,0 +1,253 @@
+# The Stoplight App
+
+The **App** component powers the Stoplight user interface by connecting users to
+the Stoplight API and other services. This is the primary point of ingress for
+most users using Stoplight. It is what they will load in their web browser, and
+connect the desktop app to.
+
+> #### Networking Details
+>
+> The default port for the App component is TCP port **3100**. The port can be
+> customized using the `PORT` configuration variable.
+>
+> The App must be able to receive **incoming** connections from the following components:
+>
+> * User Clients (web browser or desktop application)
+>
+> The App must be able to make **outgoing** connections to the following components:
+>
+> * API
+> * Prism
+> * Exporter
+
+> #### Component Dependencies
+>
+> Make sure the following components are available **before** starting the App
+> service:
+>
+> * API
+
+## Installation
+
+The Stoplight App can be installed with Docker or RPM package.
+
+### RPM Package
+
+Prior to installing the RPM package, you will need to:
+
+* Install NodeJS
+
+* Have the Stoplight package repository installed and configured with your user-specific credentials
+
+#### Installing NodeJS
+
+To install NodeJS, run the following commands:
+
+```bash
+# make sure all current versions of nodejs are removed
+sudo yum remove nodejs npm -y
+
+# install nodejs
+sudo rpm -Uvh https://rpm.nodesource.com/pub_8.x/el/7/x86_64/nodejs-8.9.4-1nodesource.x86_64.rpm
+```
+
+Once the installation has completed, verify the version installed with the command:
+
+```bash
+$ node --version
+v8.9.4
+```
+
+If you do not see a version starting `v8.9`, contact Stoplight support for assistance.
+
+#### Setting up the Package Repository
+
+You can do this by copying-and-pasting the contents below into a terminal:
+
+```bash
+# expose credentials to environment first
+REPO_USERNAME="myusername"
+REPO_PASSWORD="mypassword"
+
+# write credentials to repo file
+cat <<EOF | sudo tee /etc/yum.repos.d/stoplight.repo
+[stoplight]
+name=Stoplight Package Repository
+baseurl=https://$REPO_USERNAME:$REPO_PASSWORD@pkg.stoplight.io/rpm
+enabled=1
+gpgcheck=1
+repo_gpgcheck=1
+gpgkey=https://pkg.stoplight.io/stoplight.key
+EOF
+```
+
+> Make sure that the repository credentials are set before issuing the `cat` command above.
+
+#### Installing the App Package
+
+Once the repository is configured properly, you can install the app component using the command:
+
+```bash
+sudo yum install stoplight-app -y
+```
+
+### Docker
+
+To install the app component with Docker, run the command below:
+
+```bash
+docker pull quay.io/stoplight/app
+```
+
+> Note, if you have not already authenticated with the Stoplight container registry, you will be prompted for credentials
+
+## Configuration
+
+To configure the Stoplight App component, you will need to provide connection
+details to the other necessary Stoplight components. The API can be configured
+either by the configuration file or through the environment.
+
+> The same configuration variables can be used regardless of installation type
+> (container or package-based).
+
+### Variables
+
+#### SL_APP_HOST
+
+The `SL_APP_HOST` is the public-facing URL for the Stoplight application.
+
+```
+SL_APP_HOST="https://stoplight.example.com"
+```
+
+#### SL_API_HOST
+
+The `SL_API_HOST` is the URL to the Stoplight API.
+
+```
+SL_API_HOST="https://stoplight-api.internal.example.com:3030"
+```
+
+#### SL_GITLAB_HOST
+
+The `SL_GITLAB_HOST` is the full URL to the Stoplight GitLab instance
+
+```
+SL_GITLAB_HOST="https://gitlab.internal.example.com:8080"
+```
+
+#### SL_EXPORTER_HOST
+
+The `SL_EXPORTER_HOST` is the full URL to the Stoplight GitLab instance:
+
+```
+SL_EXPORTER_HOST="https://stoplight-exporter.internal.example.com"
+```
+
+#### SL_PRISM_HOST
+
+The `SL_PRISM_HOST` is the full URL to the Stoplight Prism instance
+
+```
+SL_PRISM_HOST="https://stoplight-prism.internal.example.com"
+```
+
+#### SL_PUBS_HOST
+
+The `SL_PUBS_HOST` variable is the top-level domain used for documentation:
+
+```
+SL_PUBS_HOST="docs.example.com"
+```
+
+#### SL_PUBS_INGRESS
+
+The `SL_PUBS_INGRESS` variable is the URL to the Stoplight Pubs instance admin API:
+
+```
+SL_PUBS_INGRESS="https://pubs.example.com:9098"
+```
+
+### RPM Package
+
+The Stoplight App configuration is located at the location:
+
+```bash
+/etc/stoplight-app/stoplight-app.cfg
+```
+
+Be sure to customize any variables as needed to match your environment
+**before** starting the API service.
+
+> Any changes to the API configuration requires a service restart in order to
+> take effect.
+
+### Docker
+
+To expose configuration variables to the Docker runtime, either write them to a
+file and use the `--env-file` argument:
+
+```bash
+cat <<EOF>app-env-vars
+SL_API_HOST="..."
+...
+EOF
+
+docker run --env-file app-env-vars ...
+```
+
+Or you can expose them one at a time with the `-e` flag:
+
+```bash
+docker run -e SL_API_HOST=https://stoplight-api.example.com ...
+```
+
+## Running
+
+### RPM Package
+
+To start the App server, run the command:
+
+```bash
+sudo systemctl start stoplight-app
+```
+
+Once started, you can see the status of the service using the command:
+
+```bash
+sudo systemctl status stoplight-app
+```
+
+### Docker
+
+To start the App container, run the command:
+
+```bash
+docker run \
+	--restart on-failure \
+	--env-file app-env \
+	-p 1234:3100 \
+	quay.io/stoplight/app:latest
+```
+
+If started properly, the container should be marked with a healthy status after
+30 seconds. Use the `docker ps` command to verify the container was started and
+is running properly.
+
+## Post-install Validations
+
+Once the App component is running, you can verify the installation was
+successful by visiting the app hostname and port in a web browser. If the web
+page loads properly (what you see when visiting the [hosted
+site](https://next.stoplight.io/login)), then you should be greeted with a login
+screen, complete with images and styling.
+
+If you would like to verify the app installation from the CLI, use `wget` to
+search for any broken links:
+
+```
+wget -r -l2 –spider -D example.com http://example.com 2>&1 | grep -B1 'broken link!'
+```
+
+> Remember to replace 'example.com' above with the domain used to install the
+> Stoplight application

articles/enterprise/components/exporter.md

@@ -0,0 +1,212 @@
+# The Stoplight Exporter
+
+The **Exporter** component de-references JSON specifications to ensure all
+referenced files and external data sources are resolved when needed.
+
+> #### Networking Details
+>
+> The default port for the Exporter component is TCP port **3031**. The port can
+> be customized using the `PORT` configuration variable.
+>
+> The Exporter must be able to receive incoming connections from the following components:
+>
+> * User Clients (web browser or desktop application)
+> * App
+> * API
+> * Prism
+>
+> The Exporter must be able to make outgoing connections to the following components:
+>
+> * API
+
+> #### Component Dependencies
+>
+> The Exporter is stateless, and has no component dependencies.
+
+## Installation
+
+The Stoplight Exporter can be installed with Docker or via RPM package.
+
+### RPM Package
+
+Prior to installing the RPM package, you will need to:
+
+* Install NodeJS
+
+* Have the Stoplight package repository installed and configured with your user-specific credentials
+
+#### Installing NodeJS
+
+To install NodeJS, run the following commands:
+
+```bash
+# make sure all current versions of nodejs are removed
+sudo yum remove nodejs npm -y
+
+# install nodejs
+sudo rpm -Uvh https://rpm.nodesource.com/pub_8.x/el/7/x86_64/nodejs-8.9.4-1nodesource.x86_64.rpm
+```
+
+Once the installation has completed, verify the version installed with the command:
+
+```bash
+$ node --version
+v8.9.4
+```
+
+If you do not see a version starting `v8.9`, contact Stoplight support for assistance.
+
+#### Setting up the Package Repository
+
+You can do this by copying-and-pasting the contents below into a terminal:
+
+```bash
+# expose credentials to environment first
+REPO_USERNAME="myusername"
+REPO_PASSWORD="mypassword"
+
+# write credentials to repo file
+cat <<EOF | sudo tee /etc/yum.repos.d/stoplight.repo
+[stoplight]
+name=Stoplight Package Repository
+baseurl=https://$REPO_USERNAME:$REPO_PASSWORD@pkg.stoplight.io/rpm
+enabled=1
+gpgcheck=1
+repo_gpgcheck=1
+gpgkey=https://pkg.stoplight.io/stoplight.key
+EOF
+```
+
+> Make sure that the repository credentials are set before issuing the `cat` command above.
+
+#### Installing the Exporter Package
+
+Once the repository is configured properly, you can install the Exporter component using the command:
+
+```bash
+sudo yum install stoplight-exporter -y
+```
+
+### Docker
+
+To install the Exporter component with Docker, run the command below:
+
+```bash
+docker pull quay.io/stoplight/exporter
+```
+
+> Note, if you have not already authenticated with the Stoplight container
+> registry, you will be prompted for credentials
+
+## Configuration
+
+To configure the Stoplight Exporter component, you will need to provide runtime
+values and connection details to the other necessary Stoplight components. The
+Exporter can be configured either by the configuration file or through the
+environment.
+
+> The same configuration variables can be used regardless of installation type
+> (container or package-based).
+
+### Variables
+
+#### SL_APP_HOST
+
+The `SL_APP_HOST` is the public-facing URL for the Stoplight App.
+
+```
+SL_APP_HOST="https://stoplight.example.com"
+```
+
+#### SL_API_HOST
+
+The `SL_API_HOST` variable is the URL to the Stoplight API.
+
+```
+SL_API_HOST="https://stoplight-api.internal.example.com:3030"
+```
+
+#### SL_EXPORTER_HOST
+
+The `SL_EXPORTER_HOST` variable is the full URL to the Stoplight Exporter instance.
+
+```
+SL_EXPORTER_HOST="https://stoplight-exporter.internal.example.com"
+```
+
+### RPM Package
+
+The Stoplight Exporter configuration is located at the location:
+
+```bash
+/etc/stoplight-exporter/stoplight-exporter.cfg
+```
+
+Be sure to customize any variables as needed to match your environment
+**before** starting the Exporter service.
+
+> Any changes to the Exporter configuration requires a service restart in order
+> to take effect.
+
+### Docker
+
+To expose these to the Docker runtime, either write them to a file and use the `--env-file` argument:
+
+```bash
+cat <<EOF>exporter-env-vars
+SL_APP_HOST="..."
+...
+EOF
+
+docker run --env-file exporter-env-vars ...
+```
+
+Alternatively, you can expose them one at a time with the `-e` flag:
+
+```bash
+docker run -e SL_APP_HOST=https://stoplight.example.com ...
+```
+
+## Running
+
+### RPM Package
+
+To start the Exporter server, run the command:
+
+```bash
+sudo systemctl start stoplight-exporter
+```
+
+Once started, you can see the status of the service using the command:
+
+```bash
+sudo systemctl status stoplight-exporter
+```
+
+### Docker
+
+To start the Exporter container, run the command:
+
+```bash
+docker run \
+	--restart on-failure \
+	--env-file exporter-env \
+	-p 2345:3031 \
+	quay.io/stoplight/exporter:latest
+```
+
+If started properly, the container should be marked with a healthy status after
+30 seconds. Use the `docker ps` command to verify the container was started and
+is running properly.
+
+## Post-install Validations
+
+Once the Exporter component is running, you can verify the installation was
+successful issuing an `HTTP GET` request to the root (`/`) endpoint:
+
+```bash
+# be sure to update the scheme, host, and port to match the installation port
+curl -v http://localhost:3031/
+```
+
+If the Exporter was installed and configured properly, you will receive an `HTTP 200` response back.

articles/enterprise/components/gitlab.md

@@ -0,0 +1,215 @@
+# GitLab CE
+
+GitLab CE powers the Stoplight backend, including file storage and database.
+GitLab is the backing datastore for all files stored within Stoplight. In
+addition to storing files, GitLab is responsible for:
+
+* Interfacing with the Stoplight API
+* User-facing notifications (including password reset emails, group/project
+  invitations, etc)
+* Tracking all changes between different files, and storing them within a Git
+  repository
+
+Packaged within the GitLab CE is an embedded installation of PostgreSQL and
+Redis. These two sub-components can be broken out into external services if your
+organization is already familiar with running these (or similar) services. You
+may also break out these services if you plan on using a managed hosting
+solution, for example, Amazon RDS (for PostgreSQL) or Amazon ElastiCache (for
+Redis).
+
+> #### Storage Requirements
+>
+> GitLab requires persistent storage in order to store Stoplight file data (in
+> Git), and optionally PostgreSQL data (when using the omnibus package).
+
+> #### Networking Details
+>
+> The default GitLab ports are 80 (HTTP) and 443 (HTTPS). These ports can be
+> customized via the `gitlab.rb` configuration file (discussed below).
+>
+> GitLab must be able to receive incoming connections from the following components:
+>
+> * App
+>
+> GitLab must be able to make outgoing connections to the following components:
+>
+> * PostgreSQL
+> * Redis
+
+> #### Component Dependencies
+>
+> Make sure the following components are available **before** starting the GitLab
+> service:
+>
+> * PostgreSQL
+> * Redis
+>
+> _Note, for Omnibus users using the embedded PostgreSQL and Redis instances,
+> these services will be started by the GitLab process._
+
+## Installation
+
+GitLab can be installed with Docker or via RPM package.
+
+### RPM Package
+
+Prior to installing the RPM package, you will need to have the Stoplight package repository installed and configured with your user-specific credentials.
+
+You can do this by copying-and-pasting the contents below into a terminal:
+
+```bash
+# expose credentials to environment first
+REPO_USERNAME="myusername"
+REPO_PASSWORD="mypassword"
+
+# write credentials to repo file
+cat <<EOF | sudo tee /etc/yum.repos.d/stoplight.repo
+[stoplight]
+name=Stoplight Package Repository
+baseurl=https://$REPO_USERNAME:$REPO_PASSWORD@pkg.stoplight.io/rpm
+enabled=1
+gpgcheck=1
+repo_gpgcheck=1
+gpgkey=https://pkg.stoplight.io/stoplight.key
+EOF
+```
+
+> Make sure that the repository credentials are set before issuing the `cat` command above.
+
+Once the repository is configured properly, you can install the GitLab component using the command:
+
+```bash
+sudo yum install stoplight-gitlab -y
+```
+
+### Docker Installation
+
+To install the app component with Docker, run the command below:
+
+```bash
+docker pull quay.io/stoplight/gitlab
+```
+
+> Note, if you have not already authenticated with the Stoplight container registry, you will be prompted for credentials
+
+## Configuring and Running
+
+To configure the Stoplight GitLab component, you will need to provide connection details to the other necessary components.
+
+### Package-based Installations
+
+#### Configuring the Service
+
+The Stoplight GitLab configuration is located at:
+
+```bash
+/etc/gitlab/gitlab.rb
+```
+
+The above file encompasses all of the different configuration options exposed by GitLab. This guide only covers those specific to Stoplight.
+
+> For documentation on other GitLab configuration options, see the official
+> documentation [here](https://docs.gitlab.com/omnibus/README.html#configuring)
+
+#### Starting the Service
+
+To start GitLab for the first time, run the commands:
+
+```bash
+# one-time configuration (needed on new installs and upgrades)
+sudo gitlab-ctl reconfigure
+
+# start the services
+sudo gitlab-ctl start
+```
+
+Once started, you can see the status of the service using the command:
+
+```bash
+sudo gitlab-ctl status
+```
+
+### Docker Installations
+
+#### Configuring the Container
+
+The GitLab container should be configured nearly identically to the package installation described above. The easiest way to do this is to mount the GitLab configuration directory inside the container.
+
+To mount the configuration inside the container, use the `-v` argument to the `docker run` command:
+
+```bash
+docker run -v /data/gitlab-config:/etc/gitlab ...
+```
+
+Where `/data/gitlab-config` is a directory containing your `gitlab.rb` configuration file.
+
+> See [here](https://docs.gitlab.com/omnibus/README.html#configuring) for more information on how to configure GitLab
+
+#### Starting the Container
+
+To start the app container, run the command:
+
+```bash
+docker run \
+        --restart on-failure \
+		-v /my/config:/etc/gitlab \
+		-p 8080:8080 \
+		quay.io/stoplight/gitlab:latest
+```
+
+If started properly, the container should be marked with a healthy status within 90 seconds (sometimes a little longer on first boot). Use the `docker ps` command to verify the container was started and is running properly.
+
+## Post-install Validations
+
+Once the GitLab component is running, you can verify the installation was successful by using the methods below.
+
+### GitLab Environment Check
+
+GitLab comes with it's own check that can be useful for catching any improperly configured components. To run this check, use the command:
+
+```bash
+sudo gitlab-rake gitlab:check RAILS_ENV=production
+```
+
+If you are using a from-source installation, the command is modified to:
+
+```bash
+sudo -u git -H bundle exec rake gitlab:check RAILS_ENV=production
+```
+
+### GitLab UI
+
+If the environment check is successful, then you are ready to load up the GitLab UI. In a web browser, visit the host and port that you are running GitLab's HTTP port on.
+
+For example, if you are running GitLab on host `gitlab.example.com` on port `8080`, you can visit the following URL in a web browser to see the GitLab UI:
+
+[http://gitlab.example.com:8080/](http://gitlab.example.com:8080/)
+
+If the installation was successful, you will be greeted by a GitLab-branded login screen similar to what is displayed on their [hosted login screen](https://gitlab.com/users/sign_in).
+
+> If you have enabled SSL, make sure to use `https://` when typing the GitLab URL.
+
+## FAQ
+
+#### Can I use the embedded Redis or PostgreSQL for other services?
+
+Yes! To expose the embedded Redis instance to the outside world, use the configuration:
+
+```ruby
+redis['bind'] = '127.0.0.1'
+redis['port'] = 6379
+```
+
+Similarly, for PostgreSQL, use the configuration:
+
+```ruby
+postgresql['listen_address'] = '127.0.0.1'
+postgresql['port'] = 5432
+```
+
+Once the configuration changes are made, issue a `gitlab-ctl reconfigure` for the changes to take effect.
+
+> If running GitLab in Docker, be sure to expose the Redis/PostgreSQL ports with the `-p` command-line option
+
+For more information on configuring Redis, see the official GitLab documentation
+[here](https://docs.gitlab.com/omnibus/settings/redis.html).

articles/enterprise/components/hub-builder.md

@@ -0,0 +1,111 @@
+# The Stoplight Hub Builder
+
+The **Hub Builder** component converts a Stoplight Hub into a standalone static HTML website, suitable for viewing and distribution.
+
+> #### Networking Details
+>
+> The Hub Builder does not have a listening service or external port configurations.
+
+> #### Component Dependencies
+>
+> The Hub Builder is started in an ad-hoc manner by **Tasker**, and does not have
+> any component dependencies.
+
+## Installation
+
+The Stoplight Hub Builder can be installed with Docker or via RPM package.
+
+### RPM Package
+
+Prior to installing the RPM package, you will need to:
+
+* Install NodeJS
+
+* Have the Stoplight package repository installed and configured with your user-specific credentials
+
+#### Installing NodeJS
+
+To install NodeJS, run the following commands:
+
+```bash
+# make sure all current versions of nodejs are removed
+sudo yum remove nodejs npm -y
+
+# install nodejs
+sudo rpm -Uvh https://rpm.nodesource.com/pub_8.x/el/7/x86_64/nodejs-8.9.4-1nodesource.x86_64.rpm
+```
+
+Once the installation has completed, verify the version installed with the command:
+
+```bash
+$ node --version
+v8.9.4
+```
+
+If you do not see a version starting `v8.9`, contact Stoplight support for assistance.
+
+#### Setting up the Package Repository
+
+You can do this by copying-and-pasting the contents below into a terminal:
+
+```bash
+# expose credentials to environment first
+REPO_USERNAME="myusername"
+REPO_PASSWORD="mypassword"
+
+# write credentials to repo file
+cat <<EOF | sudo tee /etc/yum.repos.d/stoplight.repo
+[stoplight]
+name=Stoplight Package Repository
+baseurl=https://$REPO_USERNAME:$REPO_PASSWORD@pkg.stoplight.io/rpm
+enabled=1
+gpgcheck=1
+repo_gpgcheck=1
+gpgkey=https://pkg.stoplight.io/stoplight.key
+EOF
+```
+
+> Make sure that the repository credentials are set before issuing the `cat` command above.
+
+#### Installing the Hub Builder Package
+
+Once the repository is configured properly, you can install the Hub Builder
+component using the command:
+
+```bash
+sudo yum install stoplight-hub-builder -y
+```
+
+### Docker
+
+To install the Hub Builder component with Docker, run the command below:
+
+```bash
+docker pull quay.io/stoplight/hub-builder
+```
+
+> Note, if you have not already authenticated with the Stoplight container
+> registry, you will be prompted for credentials
+
+## Configuration
+
+The Hub Builder component is an ad-hoc processing job, and does not have any
+required configuration that is not provided by the parent process (typically
+Tasker).
+
+## Running
+
+## RPM Package
+
+The Hub Builder component is an ad-hoc processing job, and does not have an
+associated service. The Tasker component is responsible for running and managing
+the Hub Builder jobs.
+
+To ensure Tasker is able to run the Hub Builder package correctly, be sure to
+set Tasker to `shell` mode in the Tasker configuration.
+
+### Docker
+
+The Hub Builder component is an ad-hoc processing job, and does not have an
+associated service. The Tasker component is responsible for running and managing
+the Hub Builder container.

articles/enterprise/components/prism.md

@@ -0,0 +1,261 @@
+# Prism
+
+The **Prism** component powers scenarios and API orchestration.
+
+> #### Networking Details
+>
+> The default port for the Prism component is TCP port **4050** (HTTP). The port can be configured via configuration (see below).
+>
+> Prism must be able to receive incoming connections from the following components:
+>
+> * User Clients (web browser or desktop application)
+> * App
+> * API
+>
+> Prism must be able to make outgoing connections to the following components:
+>
+> * Exporter
+>
+> In addition to the above requirements, Prism must be setup with a wildcard
+> subdomain (CNAME DNS record), for example `*.prism.example.com`. Each Prism
+> instance that is created gets a unique hostname associated with it, for example
+> `service1-mock.prism.example.com`.
+
+> #### Component Dependencies
+>
+> Make sure the following components are available **before** starting the API
+> service:
+>
+> * PostgreSQL
+> * Redis
+> * Gitlab
+
+## Installation
+
+Prism can be installed with Docker or via RPM package.
+
+### RPM Package
+
+Prior to installing the RPM package, you will need to have the Stoplight package
+repository installed and configured with your user-specific credentials.
+
+#### Setting up the Package Repository
+
+You can setup the Stoplight package repo by copying-and-pasting the contents
+below into a terminal:
+
+```bash
+# expose credentials to environment first
+REPO_USERNAME="myusername"
+REPO_PASSWORD="mypassword"
+
+# write credentials to repo file
+cat <<EOF | sudo tee /etc/yum.repos.d/stoplight.repo
+[stoplight]
+name=Stoplight Package Repository
+baseurl=https://$REPO_USERNAME:$REPO_PASSWORD@pkg.stoplight.io/rpm
+enabled=1
+gpgcheck=1
+repo_gpgcheck=1
+gpgkey=https://pkg.stoplight.io/stoplight.key
+EOF
+```
+
+> Make sure that the repository credentials are set before issuing the `cat` command above.
+
+#### Installing the Prism Package
+
+Once the repository is configured properly, you can install the Pubs component using the command:
+
+```bash
+sudo yum install prism -y
+```
+
+### Docker
+
+To install the Pubs component with Docker, run the command below:
+
+```bash
+docker pull quay.io/stoplight/prism-multi
+```
+
+> Note, if you have not already authenticated with the Stoplight container
+> registry, you will be prompted for credentials.
+
+## Configuration
+
+To configure the Prism component, you will need to provide runtime settings and
+connection details to the Stoplight App, API, and Exporter.
+
+### Variables
+
+#### SL_HOST
+
+The `SL_HOST` variable is the full URL to the Prism instance.
+
+```
+SL_HOST="http://%sprism.example.com"
+```
+
+Where Prism is being served from the domain `prism.example.com`. Specifying a
+port is optional.
+
+> Note, the `%s` preceding the domain is **required**.
+
+#### SL_API_HOST
+
+The `SL_API_HOST` variable is the full URL to the Stoplight API.
+
+```
+SL_API_HOST="http://api.example.com:3030"
+```
+
+#### SL_EXPORTER_HOST
+
+The `SL_EXPORTER_HOST` variable is the URL to the Stoplight Exporter.
+
+```
+SL_EXPORTER_HOST="http://exporter.example.com:3031"
+```
+
+#### ENV_NAME
+
+The `ENV_NAME` variable is a flag noting the environment level.
+
+```
+ENV_NAME="production"
+```
+
+> `ENV_NAME` should be left as `production` unless instructed otherwise by the
+> Stoplight Support staff.
+
+#### MAX_QUEUE_SIZE
+
+The `MAX_QUEUE_SIZE` variable denotes the internal queue size used to service
+requests.
+
+```
+MAX_QUEUE_SIZE=500
+```
+
+> `MAX_QUEUE_SIZE` should be left as `500` unless instructed otherwise by the
+> Stoplight Support staff.
+
+#### MAX_RUNTIME_POOL_SIZE
+
+The `MAX_RUNTIME_POOL_SIZE` variable denotes the worker pool size used to
+service requests.
+
+```
+MAX_RUNTIME_POOL_SIZE=15
+```
+
+> `MAX_RUNTIME_POOL_SIZE` should be left as `15` unless instructed otherwise by
+> the Stoplight Support staff.
+
+#### MAX_WORKERS
+
+The `MAX_WORKERS` variable denotes the number of worker threads to use when
+servicing requests.
+
+```
+MAX_WORKERS=25
+```
+
+> `MAX_WORKERS` should be left as `25` unless instructed otherwise by the
+> Stoplight Support staff.
+
+#### PRISM_LOG_LEVEL
+
+The `PRISM_LOG_LEVEL` variable denotes the log level of the Prism process.
+
+```
+PRISM_LOG_LEVEL="ERROR"
+```
+
+> `PRISM_LOG_LEVEL` should be left as `ERROR` unless instructed otherwise by the
+> Stoplight Support staff.
+
+### RPM Package
+
+The Prism configuration file is located at the location:
+
+```bash
+/etc/prism/prism.cfg
+```
+
+Be sure to customize any variables as needed to match your environment
+**before** starting the Prism service.
+
+> Any changes to the Prism configuration requires a service restart in order to
+> take effect.
+
+### Docker
+
+The Prism container can be configured either via file (see the package
+configuration above) or via environment variables. If you would like to
+configure Prism via environment variable, use the variable names directly from
+the Prism configuration above.
+
+To expose variables to the Docker runtime, either write them to a file and use the `--env-file` argument:
+
+```bash
+cat <<EOF>prism-env-vars
+SL_API_HOST="..."
+...
+EOF
+
+docker run --env-file prism-env-vars ...
+```
+
+Alternatively, you can expose them one at a time with the `-e` flag:
+
+```bash
+docker run -e SL_API_HOST=api.stoplight.example.com ...
+```
+
+## Running
+
+### RPM Package
+
+To start the Prism server, run the command:
+
+```bash
+sudo systemctl start prism
+```
+
+Once started, you can see the status of the service using the command:
+
+```bash
+sudo systemctl status prism
+```
+
+### Docker
+
+To start the Prism container, use the command:
+
+```bash
+docker run \
+	--restart on-failure \
+	--env-file prism-env-vars \
+	-p 4050:4050 \
+	quay.io/stoplight/prism-multi:latest
+```
+
+If started properly, the container should be marked with a healthy status after
+30 seconds. Use the `docker ps` command to verify the container was started and
+is running properly.
+
+## Post-install Validations
+
+Once the Prism component is running, you can verify the installation was
+successful by issuing an `HTTP GET` request to the `/health` endpoint:
+
+```bash
+curl -v localhost:4050/health
+```
+
+> Be sure to update the URL above to match your local installation
+
+If Prism was installed and configured properly, you will receive an `HTTP 200`
+response back.

articles/enterprise/components/pubs.md

@@ -0,0 +1,269 @@
+# Pubs (Hubs Server)
+
+The **Pubs** component serves and catalogs Hubs published through Stoplight.
+
+> #### Networking Details
+>
+> The default ports for the Pubs component are TCP ports **8080** (HTTP),
+> **8443** (HTTPS), and **9098** (HTTPS optional). All ports can be customized.
+>
+> Pubs must be able to receive incoming connections from the following components:
+>
+> * User Clients (on the public-facing ports, which default to 8080 and 8443)
+> * API (on the private admin port, which defaults to 9098)
+> * Tasker (on the private admin port, which defaults to 9098)
+>
+> Pubs must be able to make outgoing connections to the following components:
+>
+> * API
+
+> #### Component Dependencies
+>
+> Pubs has no component dependencies.
+
+## Installation
+
+Pubs can be installed with Docker or via RPM package.
+
+### RPM Package
+
+Prior to installing the RPM package, you will need to have the Stoplight package
+repository installed and configured with your user-specific credentials.
+
+#### Setting up the Package Repository
+
+You can setup the Stoplight package repo by copying-and-pasting the contents
+below into a terminal:
+
+```bash
+# expose credentials to environment first
+REPO_USERNAME="myusername"
+REPO_PASSWORD="mypassword"
+
+# write credentials to repo file
+cat <<EOF | sudo tee /etc/yum.repos.d/stoplight.repo
+[stoplight]
+name=Stoplight Package Repository
+baseurl=https://$REPO_USERNAME:$REPO_PASSWORD@pkg.stoplight.io/rpm
+enabled=1
+gpgcheck=1
+repo_gpgcheck=1
+gpgkey=https://pkg.stoplight.io/stoplight.key
+EOF
+```
+
+> Make sure that the repository credentials are set before issuing the `cat` command above.
+
+#### Installing the Pubs Package
+
+Once the repository is configured properly, you can install the Pubs component
+using the command:
+
+```bash
+sudo yum install pubs -y
+```
+
+### Docker Installation
+
+To install the Pubs component with Docker, run the command below:
+
+```bash
+docker pull quay.io/stoplight/pubs
+```
+
+> Note, if you have not already authenticated with the Stoplight container
+> registry, you will be prompted for credentials
+
+## Configuration
+
+To configure the Pubs component, you will need to provide connection details and
+runtime settings.
+
+### Variables
+
+#### http_bind
+
+The `http_bind` variable denotes the bind address/port to use when serving HTTP
+traffic.
+
+```yaml
+http_bind: "127.0.0.1:8080"
+```
+
+#### https_bind
+
+The `https_bind` variable denotes the bind address/port to use when serving
+HTTPS traffic.
+
+```yaml
+https_bind: "127.0.0.1:8443"
+```
+
+#### ssl_enabled
+
+The `ssl_enabled` variable denotes whether SSL should be enabled when serving
+Hub requests.
+
+```yaml
+ssl_enabled: yes
+```
+
+> If `ssl_enabled` is set to `true`, then HTTP requests will automatically be
+> redirected to HTTPS.
+
+#### admin_bind
+
+The `admin_bind` variable denotes the address/port to bind to when serving the
+admin API.
+
+```yaml
+admin_bind: "127.0.0.1:9098"
+```
+
+#### admin_ssl_enabled
+
+The `admin_ssl_enabled` variable denotes whether the admin API should accept
+connections over HTTPS (as opposed to HTTP).
+
+```yaml
+admin_ssl_enabled: no
+```
+
+#### admin_ssl_cert_path
+
+The `admin_ssl_cert_path` variable is the path to the SSL certificate to use
+when serving TLS over the admin API.
+
+```yaml
+admin_ssl_cert_path: /path/to/cert
+```
+
+> This configuration option has no effect if `admin_ssl_enabled` is not set to
+> `true`
+
+#### admin_ssl_key_path
+
+The `admin_ssl_key_path` variable is the path to the SSL key (matching the
+`admin_ssl_cert_path` option) to use when serving TLS over the admin API.
+
+```yaml
+admin_ssl_key_path: /path/to/key
+```
+
+> This configuration option has no effect if `admin_ssl_enabled` is not set to
+> `true`
+
+#### admin_ip_whitelist
+
+The `admin_ip_whitelist` variable is a list representing IP addresses that
+should be allowed to connect to the admin API.
+
+```yaml
+admin_ip_whitelist:
+  - 127.0.0.1
+```
+
+> If `admin_ip_whitelist` is not set, all IP addresses will be allowed to
+> connect to the API.
+
+#### data_dir
+
+The `data_dir` variable is the directory to use when storing builds, build
+metadata, and the pubs sqlite database.
+
+```yaml
+data_dir: /var/lib/pubs
+```
+
+#### static_ssl_domains
+
+The `static_ssl_domains` variable can be used to serve static SSL certificates
+for specific domain requests.
+
+```yaml
+static_ssl_domains:
+  - domain: "*.example.com"
+    cert-path: /path/to/example_com/certificate
+    key-path: /path/to/example_com/key
+```
+
+> Include a leading star (`*`) in the domain if the certificate is wildcarded
+> (ie, `*.example.com` for a wildcard certificate on the `example.com` domain).
+
+### RPM Package
+
+The Pubs default configuration is located at the path:
+
+```bash
+/etc/pubs/pubs.yml
+```
+
+Be sure to customize any variables as needed to match your environment
+**before** starting the Pubs service.
+
+> Any changes to the Pubs configuration requires a service restart in order to
+> take effect.
+
+### Docker
+
+The Pubs configuration can be mounted into a Docker container. As an example, if
+a Pubs configuration file is located on the host system at the path:
+
+```bash
+/data/pubs.yml
+```
+
+This file can be mounted into the running Pubs container using the `-v` argument.
+
+```bash
+docker run -v /data/pubs.yml:/etc/pubs/pubs.yml ...
+```
+
+## Running
+
+### RPM Package
+
+To start the Pubs server, run the command:
+
+```bash
+sudo systemctl start pubs
+```
+
+Once started, you can see the status of the service using the command:
+
+```bash
+sudo systemctl status pubs
+```
+
+### Docker Installations
+
+To start the Pubs container, use the command:
+
+```bash
+docker run \
+	--restart on-failure \
+	-v /path/to/pubs.yml:/etc/pubs/pubs.yml \
+	-p 80:8080 \
+	-p 443:8443 \
+	-p 9098:9098 \
+	quay.io/stoplight/pubs:latest
+```
+
+If started properly, the container should be marked with a healthy status after
+30 seconds. Use the `docker ps` command to verify the container was started and
+is running properly.
+
+## Post-install Validations
+
+Once the Pubs service is running, you can verify the installation was successful
+issuing an `HTTP GET` request to the `/health` URL on the HTTP admin port (set
+with `admin_bind`):
+
+```bash
+curl -v http://localhost:9098/health
+```
+
+> Be sure to update the URL above to match your local installation
+
+If Pubs was installed and configured properly, you will receive an `HTTP 200`
+response back.

articles/enterprise/components/tasker.md

@@ -0,0 +1,231 @@
+# Tasker (Jobs Server)
+
+The **Tasker** component runs scheduled and on-demand tasks for the Stoplight platform.
+
+> #### Networking Details
+>
+> The default port for the Tasker component is TCP port **9432**. This port can
+> be customized via configuration.
+>
+> Tasker must be able to receive incoming connections from the following components:
+>
+> * API
+>
+> Tasker must be able to make outgoing connections to the following components:
+>
+> * API
+> * Redis
+> * Pubs
+
+> #### Component Dependencies
+>
+> Make sure the following components are available **before** starting the Tasker
+> service:
+>
+> * Redis
+
+## Installation
+
+Tasker can be installed with Docker or via RPM package.
+
+### RPM Package
+
+Prior to installing the RPM package, you will need to have the Stoplight package
+repository installed and configured with your user-specific credentials.
+
+#### Setting up the Package Repository
+
+You can setup the Stoplight package repo by copying-and-pasting the contents
+below into a terminal:
+
+```bash
+# expose credentials to environment first
+REPO_USERNAME="myusername"
+REPO_PASSWORD="mypassword"
+
+# write credentials to repo file
+cat <<EOF | sudo tee /etc/yum.repos.d/stoplight.repo
+[stoplight]
+name=Stoplight Package Repository
+baseurl=https://$REPO_USERNAME:$REPO_PASSWORD@pkg.stoplight.io/rpm
+enabled=1
+gpgcheck=1
+repo_gpgcheck=1
+gpgkey=https://pkg.stoplight.io/stoplight.key
+EOF
+```
+
+> Make sure that the repository credentials are set before issuing the `cat` command above.
+
+#### Installing the Tasker Package
+
+Once the repository is configured properly, you can install the Tasker component using the command:
+
+```bash
+sudo yum install tasker -y
+```
+
+### Docker
+
+To install the Tasker component with Docker, run the command below:
+
+```bash
+docker pull quay.io/stoplight/tasker
+```
+
+> Note, if you have not already authenticated with the Stoplight container
+> registry, you will be prompted for credentials.
+
+## Configuration
+
+To configure the Tasker component, you will need to provide runtime settings and
+connection details for a running Redis instance.
+
+### Variables
+
+#### TASKER_HTTP_BIND
+
+The `TASKER_HTTP_BIND` variable is the bind address and port used for serving
+the Tasker HTTP API.
+
+```
+TASKER_HTTP_BIND="localhost:9432"
+```
+
+#### TASKER_MODE
+
+The `TASKER_MODE` variable is the operation mode that Tasker should use when
+executing jobs. Valid values for `TASKER_MODE` are `docker` and `shell`.
+
+```
+TASKER_MODE="shell"
+```
+
+> If not specified, Tasker defaults to using `docker` mode.
+
+#### CORE_ROOT
+
+The `CORE_ROOT` denotes the absolute path to the stoplight-hub-builder package
+root.
+
+```
+CORE_ROOT="/opt/stoplight-hub-builder"
+```
+
+> This variable is only required when running in `shell` mode.
+
+#### TASKER_REDIS_HOSTPORT
+
+The `TASKER_REDIS_HOSTPORT` variable denotes the Redis instance host:port to connect to.
+
+```
+TASKER_REDIS_HOSTPORT="redis://redis:6379"
+```
+
+> Redis must be available before starting service.
+
+#### TASKER_REDIS_PASSWORD
+
+The `TASKER_REDIS_PASSWORD` variable is an optional password to use when
+connecting to the Redis instance.
+
+```
+TASKER_REDIS_PASSWORD=""
+```
+
+#### TASKER_REDIS_DATABASE
+
+The `TASKER_REDIS_DATABASE` variable is the Redis database used by Tasker for
+storing job state.
+
+```
+TASKER_REDIS_DATABASE="0"
+```
+
+#### TASKER_REDIS_NAMESPACE
+
+The `TASKER_REDIS_NAMESPACE` variable is the Redis namespace used by Tasker for
+storing job state.
+
+```
+TASKER_REDIS_NAMESPACE="tasker"
+```
+
+### RPM Package
+
+The Tasker configuration is located at:
+
+```bash
+/etc/tasker/tasker.cfg
+```
+
+Be sure to customize any variables as needed to match your environment
+**before** starting the Tasker service.
+
+> Any changes to the Tasker configuration requires a service restart in order to
+> take effect.
+
+### Docker
+
+To expose configuration variables to the Docker runtime, either write them to a
+file and use the `--env-file` argument:
+
+```bash
+cat <<EOF>tasker-env-vars
+TASKER_HTTP_BIND="..."
+...
+EOF
+
+docker run --env-file tasker-env-vars ...
+```
+
+Alternatively, you can expose them one at a time with the `-e` flag:
+
+```bash
+docker run -e TASKER_HTTP_BIND=0.0.0.0:9432 ...
+```
+
+## Running
+
+### RPM Package
+
+To start the Tasker server, run the command:
+
+```bash
+sudo systemctl start tasker
+```
+
+Once started, you can see the status of the service using the command:
+
+```bash
+sudo systemctl status tasker
+```
+
+### Docker
+
+To start the Tasker container, use the command:
+
+```bash
+docker run \
+	--restart on-failure \
+	--env-file tasker-env-vars \
+	-p 9432:9432 \
+	quay.io/stoplight/tasker:latest
+```
+
+If started properly, the container should be marked with a healthy status after
+30 seconds. Use the `docker ps` command to verify the container was started and
+is running properly.
+
+## Post-install Validations
+
+Once the Tasker component is running, you can verify the installation was
+successful issuing an `HTTP GET` request to the `/health` endpoint:
+
+```bash
+# remember to update the scheme, host, and port here to match your installation
+curl -v http://localhost:9432/health
+```
+
+If Tasker was installed and configured properly, you will receive an `HTTP 200`
+response back.

articles/enterprise/maintenance/backups.md

@@ -0,0 +1,58 @@
+# Backups
+
+Backups are a critical component to ensuring the health of the Stoplight
+platform. When creating a backup and restore strategy for your on-premise
+installation, be sure to include the following locations:
+
+* The **GitLab data directory**, which includes the raw filesystem data backing each projects Git repository.
+* The **GitLab configuration directory**, which includes randomly-generated secrets and keys necessary for securing the GitLab runtime.
+* The **GitLab PostgreSQL database**, which includes user, group, permissions, and other relational data not included in the Git repositories.
+* The **Pubs data directory**, which includes published hubs and their corresponding configurations.
+
+Backing up all locations above will ensure you can properly restore a Stoplight
+installation without data loss.
+
+## GitLab Backup Procedures
+
+GitLab is a critical piece of the Stoplight platform. Stoplight recommends, at a
+minimum, daily backups of the GitLab database and filesystem to ensure minimal
+data loss in the event of a failure.
+
+To run a backup for GitLab, which includes a snapshot of the filesystem and
+database, run the command:
+
+```bash
+sudo gitlab-rake gitlab:backup:create
+```
+
+Backups are in zip format, making them very easy to store in remote or cloud
+storage. GitLab also offers built-in capabilities that provide automatic uploads
+to cloud storage providers when configured.
+
+> If you do not use the built-in backup utility, it is critical that _both_ the
+> PostgreSQL database and filesystem data (including data directories and
+> configuration directories) be recorded.
+
+For more information, please see the official GitLab backup documentation
+[here](https://docs.gitlab.com/ce/raketasks/backup_restore.html).
+
+## Pubs Backup Procedures
+
+Pubs stores all published hubs created via the Stoplight application. While not
+critical to the health of the Stoplight Enterprise platform, it is recommended
+that the pubs data directory is backed up on a regular basis.
+
+To perform a backup of the Pubs data directory, take a tarball snapshot of the
+Pubs data directory and configuration directory. By default, the Pubs data
+directory is located at `/var/lib/pubs`, and the configuration directory is
+located at `/etc/pubs`.
+
+To perform a backup, run the command:
+
+```bash
+sudo tar -cvzf pubs-backup.$(date +%s).tar.gz /var/lib/pubs /etc/pubs
+```
+
+Once the backup is completed, the tarball output can be stored on redundant or
+cloud storage. To ensure you have a recent backup available at all times,
+Stoplight recommends taking a backup daily.

articles/enterprise/overview.md

@@ -0,0 +1,99 @@
+# Stoplight Enterprise
+
+The Stoplight Enterprise platform provides a fully-functional on-premise API
+design, test, and documentation tool-kit, taking the hassle out of your API
+strategy.
+
+## Deployment Options
+
+Stoplight can be deployed on one or many Linux servers (dedicated or
+virtualized).
+
+### Single-Server
+
+Single-server deployments run all of the necessary Stoplight components on a
+single Linux instance. This greatly simplifies the deployment process, as all
+components do not have to reach over the network to talk to one another.
+
+Despite ease of installation, there are some notable shortcomings to this
+option:
+
+* If the system is taken down for any reason, all components will be
+  unavailable.
+
+* Any single component can affect the performance of the entire Stoplight
+  platform, leading to service degradation across all components.
+
+Due to these shortcomings, single-server deployments are only recommended for
+POC, pilot, or trial environments.
+
+### Multi-Server
+
+Multi-server deployments run different Stoplight Enterprise components on
+separate Linux instances. This deployment option is much more resilient to
+system-level issues, though it does require more network configuration.
+
+Stoplight recommends multi-server deployments for all production installations.
+
+### Native vs. Container-based Deployments
+
+The Stoplight platform can be run either with a container solution (Docker) or
+natively on the Linux system via RPM package installation. Both options are
+fully supported, however Stoplight recommends leveraging containers where
+possible for ease-of-use and improved security/sandboxing.
+
+## System Requirements
+
+Stoplight currently supports the following Linux distributions for on-premise installations:
+
+* Ubuntu 16.04 LTS (x86_64)
+* CentOS / RedHat Enterprise Linux 7 (x86_64)
+
+A minimum of one server is required to run the Stoplight application, however,
+for a production installation, we recommend at least four servers (excluding
+monitoring and backup servers). The system specifications for each server can be
+found below under each component.
+
+### Docker Installations
+
+For the recommended Docker-based installation path, Stoplight recommends [Docker
+CE](https://www.docker.com/) v18.00+.
+
+### RPM Installations
+
+For RPM-based installations, the application requirements vary by component and
+are addressed in the component pages referenced below.
+
+## Stoplight Components
+
+![](https://s3.amazonaws.com/user-content.stoplight.io/1564/1520952929100)
+
+The Stoplight platform is broken up in to seven main components:
+
+1.  [Stoplight App](/enterprise/components/app)
+2.  [Stoplight API](/enterprise/components/api)
+3.  [Stoplight Exporter](/enterprise/components/exporter)
+4.  [Prism](/enterprise/components/prism)
+5.  [Tasker (Jobs Server)](/enterprise/components/tasker)
+    * [Hub Builder](/enterprise/components/hub-builder)
+6.  [Pubs (Hubs Server)](/enterprise/components/pubs)
+7.  [GitLab CE - Stoplight Fork](/enterprise/components/gitlab)
+
+Please review each of the component pages prior to the installation.
+
+## Monitoring
+
+For monitoring purposes, Stoplight runs and recommends the following
+applications:
+
+* [InfluxDB](https://www.influxdata.com/time-series-platform/influxdb/) v1.3
+  for metrics storage and aggregation
+* [Kapacitor](https://www.influxdata.com/time-series-platform/kapacitor/) v1.3
+  for alerting and metrics processing
+* [Telegraf](https://www.influxdata.com/time-series-platform/telegraf/) v1.4
+  for metrics collection
+* [Mtail](https://github.com/google/mtail) v3.0 for whitebox monitoring of
+  application logs
+
+> Please note that the above recommendations are entirely optional if your
+> organization already has a monitoring and alerting solution in place.

articles/getting-started/new-user-introduction.md

@@ -1,6 +1,6 @@
 # Welcome to Stoplight Next! 
 
-Now that you have the basics on what the [Stoplight Next Platform](/platform/introduction) is, we can go over how to get started. 
+Now that you have the basics on what the [Stoplight Next Platform](/platform/what-is-stoplight) is, we can go over how to get started. 
 
 First things first, are you using Stoplight for Personal Projects or as part of an Organization?
 

articles/getting-started/permissions-overview.md

@@ -1,15 +1,15 @@
-# Permissions & Governance Overview 
+# Roles & Permissions Overview 
 
 ## Organizations 
 
-| **Organization Actions**        | **Guest** | **Member** | **Administrator** | **Owner** |
-|---------------------------------|:-----------:|:------------:|:-------------------:|:-----------:|
+| **Organization Actions**        | **Reader** | **Creator** | **Administrator** | **Owner** |
+|---------------------------------|:----------:|:-----------:|:-----------------:|:---------:|
 | Read Public Projects            |     X     |      X     |         X         |     X     |
 | View Organization Collaborators |           |      X     |         X         |     X     |
 | View Organization Teams         |           |      X     |         X         |     X     |
 | Create Projects                 |           |      X     |         X         |     X     |
 | Read Private Projects           |           |      X     |         X         |     X     |
-| Write Projects                  |           |            |         X         |     X     |
+| Write Projects                  |           |      X     |         X         |     X     |
 | Manage Collaborators            |           |            |         X         |     X     |
 | Manage Teams                    |           |            |         X         |     X     |
 | Manage Organization Settings    |           |            |                   |     X     |

articles/hubs/blocks.md

@@ -1,6 +1,6 @@
 # Blocks 
 
-![Blocks](https://github.com/stoplightio/docs/blob/develop/assets/gifs/blocks.gif?raw=true)
+![Blocks](https://github.com/stoplightio/docs/blob/develop/assets/gifs/Blocks.gif?raw=true)
 
 ## What
 Blocks are the micro-level building blocks of Hubs. They house multiple forms of content and allow for simple restructuring and modification. 
@@ -22,12 +22,6 @@ Blocks are the micro-level building blocks of Hubs. They house multiple forms of
 * An upper level block for organizing text within tabs 
 ### Callout 
 * A text block with color for emphasis 
-### Hero 
-* A large stylized text block with additional functionality typically found on landing pages 
-### Bar List 
-* A navigational block composed of bars with buttons 
-### Card List 
-* A navigational block composed of cards with text, buttons, and optional images
 ### HTML 
 * Include arbitrary HTML in your hubs when the other base block types don't quite do the trick
 
@@ -35,7 +29,7 @@ Blocks are the micro-level building blocks of Hubs. They house multiple forms of
 **Related Articles**
 - [Documentation with Hubs](/documentation/introduction)
 - [Routing](/documentation/getting-started/routing)
-- [Headers & Footers](/documentation/getting-started/header-footer)
+- [Headers](/documentation/getting-started/header-footer)
 - [Pages](/documentation/getting-started/pages)
 - [Subpages](/documentation/getting-started/subpages)
 - [Referencing Other Data Sources](/documentation/referencing-other-data-sources)

articles/hubs/custom-css.md

@@ -1,11 +1,17 @@
 # Custom CSS
 
+![Applying Custom CSS](https://github.com/stoplightio/docs/blob/develop/assets/gifs/hubs-custom-css.gif?raw=true)
+
+## What 
+
+Want to add some style and flair to your documentation? Add your own custom CSS to enhance your Hub’s look and feel. Below are some of the classes you can modify: 
+
 ```
 .Hub
   .HubHeader
     .HubHeader-section
       .HubHeaderItem.is-active
-        .HubHeaderItem-name 
+        .HubHeaderItem-name
   .HubMain
     .HubSidebar-overlay
     .HubSidebar-wrapper
@@ -17,7 +23,24 @@
         .HubPage-inner
           .HubPage-content
             .HubPageCrumbs
-              .HubPageCrumb
-            .HubPageBody
+              .HubPageCrumb 
+            .HubPageBody 
+              .HubBlock
             .HubPageFooter
 ```
+
+## How
+
+1. Select the Hub you wish to modify 
+2. Select the **Design View**
+3. Click on **Theme** in the top toolbar 
+4. Select **Custom CSS** in the bottom left 
+5. Input CSS in the text area at the bottom of the page 
+6. Input CSS in the generated **theme** file (optional)
+7. In publishing, check the **Custom CSS** box under **Advanced** to apply the Custom CSS to that Hub when published
+
+>After accessing Custom CSS, a **theme** file will be generated under Documentation in the file explorer. After making changes to your CSS, make sure to save the **theme** file. 
+
+---
+**Related Articles**
+- [Theming](/documentation/design/theming)

articles/hubs/export-static-html.md

@@ -0,0 +1,31 @@
+# Download Static HTML & CSS
+
+![Download Static HTML and CSS](https://github.com/stoplightio/docs/blob/develop/assets/gifs/export-static-html.gif?raw=true)
+
+> Requires a Pro Docs plan 
+
+## What 
+If you would rather host your documentation outside of Stoplight's hosted servers, you can download a built version of your Hub. Downloading a build will produce a `.zip` containing all of the minified assets necessary to load your Hub. These assets will include HTML, JAvascript, CSS, and JSON files. 
+
+## How to Download
+1. Click the **Publish** icon on the far left toolbar 
+2. Select or create a **domain**
+3. Choose a **Hub** or **OAS** file to create a build from 
+4. Click the **Build** button to start the build process. 
+
+> If this is your first build, it will also publish to your selected domain 
+
+5. Once your **Hub** has finished building, it will appear in the **Builds** section. Click the download icon to the right of the build 
+---
+**Related Articles**
+- [Documentation with Hubs](/documentation/introduction)
+- [Routing](/documentation/getting-started/routing)
+- [Headers](/documentation/getting-started/header-footer)
+- [Pages](/documentation/getting-started/pages)
+- [Subpages](/documentation/getting-started/subpages)
+- [Blocks](/documentation/blocks)
+- [Referencing Other Data Sources](/documentation/referencing-other-data-sources)
+- [Publishing](/documentation/publishing)
+- [Theming](/documentation/design/theming)
+- [Custom CSS](/documentation/design/custom-css)
+

articles/hubs/oauth.md

@@ -0,0 +1,56 @@
+# OAuth for Hubs 
+
+## What 
+
+OAuth provides a level of security to your documentation to restrict access to it. If your API is protected by OAuth, you will need to enable it for Try It Out. Enabling OAuth for Try It Out can be accomplished through two different methods: via Modeling or directly into the Hubs code.
+
+> Stoplight supports OAuth 1.0 and 2.0 
+
+## How 
+
+### Modeling 
+
+![OAuth in Modeling](https://github.com/stoplightio/docs/blob/develop/assets/images/hubs-oauth-modeling.png?raw=true)
+
+1. Create a new Modeling file or select an existing one referenced by the Hub you wish to modify 
+
+> If you are creating a new Modeling file, make sure to reference it in your Hub 
+
+2. Next to **Security** in the left-middle toolbar, Add a Security Scheme by clicking the **+**
+3. Input a **key**
+4. Select oauth2 under **type** 
+5. Select **accessCode** under OAuth **flow** 
+6. Select an **authorization url**
+7. Select a **token url** 
+8. **Add Scope** (optional) 
+9. Add a **Security scheme description** (optional)
+
+### Hubs 
+
+![OAuth in Hubs](https://github.com/stoplightio/docs/blob/develop/assets/images/hubs-oauth-code.png?raw=true)
+
+1. Select the Hub you wish to modify 
+2. Select **Code View**
+3. Add the following lines of code to your Hub:
+
+```
+
+"config": {
+  "http": {
+    "oauth2": {
+      "credentials": {
+        "authorize_url": "insert authorize url here",
+        "access_token_url": "insert access token url here",
+      }
+    }
+  }
+}
+
+```
+
+---
+**Related Articles**
+
+- [Digital Oceans: Introduction to OAuth2](https://www.digitalocean.com/community/tutorials/an-introduction-to-oauth-2)
+- [Security Schemes](/modeling/modeling-with-openapi/security-schemes)
+

articles/modeling/grouping-tagging.md

@@ -0,0 +1,16 @@
+# Grouping & Tagging Endpoints in OpenAPI
+
+![Tagging and Grouping Endpoints](https://github.com/stoplightio/docs/blob/develop/assets/gifs/modeling-tagging.gif?raw=true)
+
+## What
+
+Use tags to group API endpoints and provide an additional layer of organization in your OpenAPI files. When rendering your OpenAPI in read view, Stoplight will group API endpoints by their first tag.
+
+## How
+
+1. Click **Tag** in the top Modeling toolbar 
+2. Input a **Name** 
+3. Input a **Tag description** (optional) 
+4. Select the endpoint you want to tag 
+5. Open the **tags** dropdown, and select the tag that you just created
+6. Switch to read view and you should see the endpoint grouped under that tag in the sidebar

articles/modeling/json-introduction.md

@@ -43,7 +43,7 @@ There are many benefits to using JSON, some of which include:
   be written in YAML, so either format can be used to write OpenAPI specifications
 
 * It can be used to link files together through [JSON
-  references](/modeling/introduction/modeling-with-openapi/referencing-another-api-spec), making it easy to break up large documents
+  references](/modeling/modeling-with-openapi/referencing-another-api-spec), making it easy to break up large documents
   into smaller, more focused documents
 
 Whether you are modeling an API, creating a Prism Collection, or writing

articles/modeling/modeling-introduction.md

@@ -30,4 +30,4 @@ There are a few ways to get started designing your API with the Stoplight design
 - Create an API from scratch [Using the CRUD Builder](/modeling/modeling-with-openapi/using-the-crud-builder)
 - [Reference another API Spec](/modeling/modeling-with-openapi/referencing-another-api-spec)
 - [Send HTTP Requests](/modeling/modeling-with-openapi/sending-http-requests) to an existing API Spec 
-- [Validate your API Spec](/modeling/modeling-with-openapi/validating-your-api-sec)
+- [Validate your API Spec](/modeling/modeling-with-openapi/validating-your-api-spec)

articles/modeling/sending-http-requests.md

@@ -31,4 +31,5 @@ Use the HTTP Request Maker to send requests to the endpoints defined in your spe
 
 ---
 **Related Articles**
-[Using Environment Variables](/testing/using-variables/environment)
+
+- [Using Environment Variables](/testing/using-variables/environment)

articles/organizations/create-org.md

@@ -5,9 +5,6 @@
 ## What 
 Organizations are great for grouping people, data, and billing together in one convenient location. 
 
-## Who 
-* Only the Billing **Owner** or Organization **Administrators** can create Organizations 
-
 ## How 
 1. Click on **+ New**  to the right of Organizations 
 2. Fill in **Name** 

articles/organizations/managing-people.md

@@ -3,12 +3,14 @@
 ![Invite People to an Organization](https://github.com/stoplightio/docs/blob/develop/assets/gifs/org-invite-members.gif?raw=true)
 
 ## What 
-Adding people to your Organization is the first step towards collaboration within Stoplight.
+Adding people to your Organization is the first step towards collaboration within Stoplight. There are two methods of inviting people to your Organization: inputting email addresses or by generating Magic Links. Inputting email addresses send invitations directly to that person's email. Magic Links allow you to invite people via a simple link.
 
 ## Who 
 * Only an Organization **Owner** or **Administrator** can invite people to an Organization 
 
 ## How
+
+### Inviting via Email Addresses  
 1. From the Stoplight homepage, select the **Organization** you would like to invite people to 
 2. Select the **People** tab from the tabs bar 
 3. Click **Invite Member** 
@@ -16,6 +18,24 @@ Adding people to your Organization is the first step towards collaboration withi
 5. Hit **enter** to add them to your list 
 6. Once completed, click the **Invite** button 
 
+### Magic Link 
+
+> Magic Link grants either Creator or Reader Permissions. Set accordingly 
+
+#### Generating and Sending Magic Link 
+1. Select the **Organization** you wish to invite people to 
+2. Select the **People** tab 
+3. Click **Invite Member**
+4. Select a role, either **Creator** or **Reader**
+5. Click **Generate Link**
+6. Send link to invitee 
+
+#### Accepting Magic Link 
+1. Click on the **magic link** 
+2. If new to Stoplight, click **Register**
+3. If you already have an account, **Login** 
+4. You now have Creator or Reader access to that Organization 
+
 ---
 **Related Articles**
 - [Invite People & Teams](/platform/projects/invite-people)

articles/organizations/roles.md

@@ -10,8 +10,8 @@ Roles and Permissions for members of Organizations can be managed and modified w
         * Has access to Billing and Organization Settings
     * **Administrator** 
         * Admins can update the org, its connections, and its members 
-    * **Member** 
-         * Members can update the org and its connections. They can view its members 
+    * **Creator** 
+         * Creators can update the org and its connections. They can view its members 
 
 ## Who
 * Only an Organization **Owner** or **Administrator** can modify roles and permissions 

articles/playbooks/technical-writers.md

@@ -0,0 +1,43 @@
+# Technical Writer Playbook 
+
+Documenting an API is crucial to its success but can be extremely time consuming. Here at Stoplight, we believe documentation should be beautiful, clean, and robust while maintaining a streamlined turnaround time. We’ve created a holistic documentation tool, Hubs, to address some of the problems our users were facing including:
+ 
+- Documenting Endpoints 
+- Testing Endpoints 
+- Creating Non-Reference Documentation 
+- Managing Content
+- External and Internal Referencing 
+- Design and Style 
+
+
+## Documenting Endpoints 
+The most key component to API Documentation are its endpoints. To that end, we created a reference builder that allows you to [“power pages”](/documentation/referencing-other-data-sources) with your specification as you see fit. When you power a page or subpage with your specification, the endpoints are automatically documented and styled for legibility and aesthetic design. 
+
+## Testing Endpoints 
+Testing endpoints is a valuable tool for anyone who wants to consume your API. Users want to know that your API functions properly before they commit to using it. To address this problem, we created [“Try it Out,” an HTTP Request Maker](/modeling/modeling-with-openapi/sending-http-requests). Try it Out allows you to send HTTP Requests to your API to test out its endpoints under any number of different conditions. You can customize Try it Out with security schemes, variables, headers, queries, and it even generates code in various programming languages. 
+
+## Creating Non-Reference Documentation 
+Great documentation is more than just API endpoints. Guides, tutorials, and other supplemental information enhance your users experience by providing them with all the information they need to access your API and your product. We broadened Hubs scope to accomodate all product documentation needs. You can easily build out your content within [Blocks](/documentation/blocks), a number of flexible content structures that can house a number of different forms of content including markdown, images, code snippets, and much more. 
+
+## Managing Content 
+Organizing a complex APIs endpoints and supplemental information can be a challenging task. Some specification can have hundreds of endpoints with supplemental information throughout. To assist with organizing content, we created an overview of all your pages, subpages, and their connections called “Table of Contents”. With a bird’s eye view of your content, you can easily organize and manage your content through drag drop functionality. 
+
+## External and Internal Referencing 
+To accomodate a larger variety of writing workflows, we expanded the capabilities of [Powering a Page](/documentation/referencing-other-data-sources) to allow for more files internally and externally to be referenced. You can now easily reference internal or external specifications, and Markdown, YAML, JSON, and Scenario files. 
+
+## Design and Style 
+We wanted to create a new, beautiful, minimalistic, efficient design for less design-oriented individuals while allowing for customization. Hubs was designed to display your documentation in a neat, efficient structure, designed specifically for displaying the real beauty, your API. On the other hand, we didn’t want to stifle the creativity that goes into documentation design so we added in [theming](/documentation/design/theming) and [custom CSS](/documentation/design/custom-css). We also made it easier to add navigation, different kinds of content, and a more robust search. 
+
+---
+**Related Links** 
+- [Documentation with Hubs](/documentation/introduction)
+- [Routing](/documentation/getting-started/routing)
+- [Headers](/documentation/getting-started/header-footer)
+- [Pages](/documentation/getting-started/pages)
+- [Subpages](/documentation/getting-started/subpages)
+- [Blocks](/documentation/blocks)
+- [Referencing Other Data Sources](/documentation/referencing-other-data-sources)
+- [Publishing](/documentation/publishing)
+- [Theming](/documentation/design/theming)
+- [Custom CSS](/documentation/design/custom-css)
+

articles/prism/introduction.md

@@ -0,0 +1,59 @@
+# Introduction
+
+Prism is a proxy and API server toolkit that helps you test, mock, validate, and orchestrate your online applications. We rebuilt Prism from the ground up to be performant, powerful, and programmable while still being practical. Prism enables teams to work in parallel and iterate faster with less errors. The Stoplight Platform integrates tightly with Prism to generate test coverage of your API automatically, build tests visually, and create mock and contract servers instantly.
+
+Prism has first class support for the OpenAPI Specification (aka OAS) and Stoplight Scenarios. OAS is machine readable documentation of your API that Prism can read and understand. Scenarios tell Prism how to orchestrate your API. When you use them together you can easily assert, transform, and validate your API against your OAS. Prism also allows your front-end team to work in tandem with your back-end team. While the back-end team implements your API, your front-end teams can implement against a mock server that can return static examples, dynamic data, or replay actual traffic from your API.
+
+![Prism Overivew](https://github.com/stoplightio/docs/blob/develop/assets/images/prism-introduction-help.png?raw=true)
+
+## Features
+
+* Act as a mock server, routing incoming requests to example responses, or dynamically generating examples on the fly
+* Act as a transformation layer, manipulating incoming requests and outgoing responses
+* Act as a validation layer, validating incoming requests, and outgoing responses
+* Contract test your APIs
+* Extend existing APIs with new endpoints or capabilities
+* Act as a system-wide proxy, blocking traffic to particular websites or endpoints
+
+## Conduct vs Serve
+
+Conduct and Serve are important concepts to understand when using Prism.
+
+* Conduct is an isolated scenario run. You tell Prism what scenarios you want to run, give it an environment to run against, and Prism will generate a report of the run
+
+* Serving, on the other hand, is a long running instance of Prism that applies scenarios to HTTP traffic
+
+### Conduct Use Cases
+
+1.  Debugging your API implementation or specification
+2.  Integrating with your CI/CD Environment: Catch bugs before they get to your actual API Consumers
+3.  Webhooks: Generate your OAS from code, automatically upload it to Stoplight
+
+![Prism Conduct](https://github.com/stoplightio/docs/blob/develop/assets/gifs/prism-introduction-conduct.gif?raw=true)
+
+### Serve Use Cases
+
+1.  Mocking back one or more specifications: Useful to help teams work in parallel and simplify testing dependencies.
+2.  Validating live traffic between your client/backend.
+3.  Your API, your workflow, your Prism. Prism is very flexible. You can easily create an instance that will record your API traffic, save it to S3, and then create another instance that will replay that API traffic.
+
+![Mock Server](https://github.com/stoplightio/docs/blob/develop/assets/gifs/prism-introduction-mock.gif?raw=true)
+
+### Stoplight Prism Helpers
+
+The [Prism Helpers](https://next.stoplight.io/stoplight/prism) project is a collection of scenarios, specifications, and Prism instances that illustrate how to use Prism effectively. Please go [here](https://community.stoplight.io) and let us know what you would like to see.
+
+---
+
+**Related Articles**
+
+* [Javascript Runtime](/mocking/javascript-runtime)
+* [Running Tests In Stoplight](/testing/running-tests/in-stoplight)
+* [Running Tests in the Terminal](/testing/running-tests/in-the-terminal)
+* [Running Tests Triggered by URL](/testing/running-tests/triggering-by-url)
+* [Using Variables Overview](/testing/using-variables/overview)
+* [$$.env (Environment)](/testing/using-variables/environment)
+* [$.ctx(Context)](/testing/using-variables/context)
+* [Sending HTTP Requests](/testing/sending-http-requests/overview)
+* [Contract Testing](/testing/leveraging-openapi/contract-testing)
+* [Integrating in Continuous Integration](/testing/continuous-integration/overview)

articles/prism/overview.md

@@ -1,61 +0,0 @@
-# Mocking with Prism 
-
-Prism is a performant, dependency free server, built specifically to work with web APIs. 
-
-### Features 
-- Act as a mock server, routing incoming requests to example repsonses, or dynamically generating examples on the fly. 
-- Act as a transformation layer, manipulating incoming requests and outgoing responses. 
-- Act as a validation layer, validating incoming requests and outgoing responses. 
-- Contract test your APIs, given an OAS(Swagger 2) file. 
-- Log all or a subset of traffic to configurable locations. 
-- Extend existing APIs with new endpoints or capabilites. 
-- Act as a system-wide proxy, blocking traffic to particular websites or endpoints. 
-
-### Simplicity Redefined 
-Run it anywhere. It runs on OS X, Windows, and Linux, with no external dependencies. It is a single, self-contained binary file, that you can easily run from your terminal with a single command.  
-
-## Getting Started 
-
-#### macOS and Linux 
-
-```# Install Prism 
-curl https://raw.githubusercontent.com/stoplightio/prism/master.install.sh | sh
-```
-
-#### Windows 
-Download the appropriate binary from [here](https://github.com/stoplightio/prism/releases). Unzip the binary file, then navigate in your terminal to the folder where you extracted Prism. 
-
-### Run a Simple Mock Server 
-Prism understands OAS(Swagger 2), so let's get started by spinning up a quick mock server for the popular Petstore API. To do this, run the following command in your terminal: 
-
-```# os x / linux
-prism run --mock --list --spec http://petstore.swagger.io/v2/swagger.json
-
-# windows 
-path/to/prism.exe run --mock --list --spec http://petstore.swagger.io/v2/swagger.json
-```
-
-Here, you are using the "run" command to run a server based on the spec file passed in via the --spec argument. The spec location can be the filepath to a file on your computer, or the URL to a publicly hosted file. The mock argument tells Prism to mock all incoming requests, instead of forwarding them to the API host described in the spec file. The list argument is a convenience, and tells Prism to print out the endpoints in the spec on startup. 
-
-Prism starts on port 4010 by default - try visiting ```http://localhost:4010/v2/pet/findByStatus``` in your browser. This is one of the endpoints described in the petstore spec you passed in. You'll notice that it returns an error about a required query string parameter "status". This is the automatic request validation at work! The swagger spec specifies that a query string parameter names "status" is required for this endpoint so Prism simulates a 400 response for you. Reload the page with a query string parameter, and you will see the dynamically generated mock response ```http://localhost:4010/v2/pet/findByStatus?status=available```.
-
-Tada! With a single command you have started a validating, dynamically mocking version of the Swagger petstore API. 
-
-### Run some Contract Tests
-
-Prism consumes OAS(Swagger 2) files. OAS provides the contract for your API. If your OAS file contains the x-tests extension (generated automatically if you use the Stoplight app to manage your OAS and tests) then you can run tests with Prism.
-
-Check out [this specification](https://goo.gl/jniYmw). If you scroll past all the regular OAS properties, you will notice a ```x-tests``` extension near the bottom of the file. Inside of that property, we have a few test cases defined. This OAS file, along with its tests, is managed in the Stoplight app (we export our API from within the app to produce this file). 
-
-#### To Run the Contract Tests 
-```
-# os x / linux 
-prism test --spec https://goo.gl/jniYmw
-
-# windows
-path/to/prism.exe test --spec https://goo.gl/jniYmw
-```
-
-You should see some nice output to your terminal detailing the tests and assertions that are run. These tests take our OAS contract and apply it to your API. They act as a sort of sync manager. 
-
-> If a test fails, it means one of two things - your API is broken or, our OAS contract is out of date / incorrect 

articles/prism/runtime.md

@@ -120,10 +120,11 @@ var data = SL.schema.generate(contract);
 
 #### Find Operation
 
+The code snippet below describes the Stoplight representation of an HTTP operation. It is loosely based on OAS 3. You can find more descriptions of some of the properties described below [here](https://swagger.io/specification/#operationObject).
+
 ```js
 /**
 *
-* This describes the Stoplight representation of an HTTP operation. It is loosely based on OAS 3. You can find more descriptions of some of the properties described below here: https://swagger.io/specification/#operationObject.
 *
 * @typedef {Object} Operation
 * @property {string} method

articles/projects/git.md

@@ -0,0 +1,61 @@
+# Git Repositories
+ 
+## What 
+The Stoplight Platform is built on top of Git. This means that all your projects are Git repositories and that our platform benefits from all the additonal functionality provided by Git. To access the Git funtionality, you will need to clone your Git repository by generating an Access Token.  
+
+> You can also use Access Tokens to access the Stoplight API, authenticate Prism in a continuous integration enviornment, and access the underlying Git repositories for projects. You can make this part of your Git workflow, add it to scripts, or your CI/CD process
+
+## Who 
+
+If you have write access to a project, you will be able to:
+* Pull projects via Git
+* Commit to projects via Git
+* Push changes to projects via Git
+
+If you have read access to a project, you will be able to:
+* Pull your project via Git
+
+## How to Clone Your Stoplight Git Repository 
+  
+1. Select the **Settings** tab on the platform homepage
+2. Select **Access Tokens** from the left  
+
+![Access Tokens](https://github.com/stoplightio/docs/blob/develop/assets/images/access-tokens.png?raw=true)
+
+3. Create a token to access projects that your Stoplight account has proper permissions for (These permissions match the ones in the Stoplight UI) 
+
+> You can name your token whatever you want. Once you have created the token, copy it, and only store it in a safe location. Once you close the window, you will not see it again
+
+3. On your machine, store your access token as an environmental variable (recommended)
+
+For example, on Mac/Linux:
+
+```
+export STOPLIGHT_TOKEN="1234567890"
+```
+
+4. You can then `git clone` the repo, replace `{stoplight-username}`, `{username}`, and `{project-name}` with the appropriate information: 
+
+```
+git clone https://{stoplight-username}:$STOPLIGHT_TOKEN@git.stoplight.io/{username}/{project-name}.git
+```
+
+For example: 
+
+```
+git clone https://taylor:$STOPLIGHT_TOKEN@git.stoplight.io/taylor/test-new.git
+```
+
+> If the project is associated with an organization and not a personal project, replace `username` with `organization-name` 
+
+5. Now you can make changes to your files, commit, and push to your master branch. You can see these changes in the Stoplight UI as well as the "History of Changes" 
+
+> Remember: You will only see changes on the master branch in the UI at this time. 
+
+    
+---
+**Related Articles**
+- [Change a Project Member's Role](/platform/projects/change-a-members-role)
+- [Make Your Project Private/Public](/platform/projects/visibility)
+- [Invite People to Organization](/platform/organizations/invite-people)
+- [Add People to a Team](/platform/organizations/teams/add-people)

articles/projects/visibility.md

@@ -1,4 +1,4 @@
-## Making Your Project Private & Public
+# Making Your Project Private & Public
 
 ![Project Visibility](https://github.com/stoplightio/docs/blob/develop/assets/images/project-make-public.png?raw=true)
 

articles/robbins.md

@@ -1 +0,0 @@
-

articles/teams/delete-team.md

@@ -19,4 +19,4 @@
 **Related Articles**
 - [Delete an Organization](/platform/organizations/delete-org)
 - [Transfer Ownership of a Team](/platform/organizations/teams/transfer-ownership)
-- [Delete a Team](/platform/organizations/teams/delete)
+

articles/testing/contract-testing.md

@@ -86,7 +86,6 @@ Any validation errors will automatically be added to the test results.
 ---
 **Related Articles**
 - [Testing Introduction](/testing/introduction)
-- [Passing Data Between Steps](/testing/getting-started/passing-data-between-steps)
 - [Running Tests In Stoplight](/testing/running-tests/in-stoplight)
 - [Running Tests in the Terminal](/testing/running-tests/in-the-terminal)
 - [Running Tests Triggered by URL](/testing/running-tests/triggering-by-url)
@@ -94,4 +93,4 @@ Any validation errors will automatically be added to the test results.
 - [$$.env (Environment)](/testing/using-variables/environment)
 - [$.ctx(Context)](/testing/using-variables/context)
 - [Sending HTTP Requests](/testing/sending-http-requests/overview)
-- [Referencing other Scenarios](/testing/referencing-other-scenarios/overview)
+

articles/testing/overview.md

@@ -24,11 +24,10 @@ API tests provide insight into how your API behaves under certain scenarios and
 
 Microservices and serverless architecture have made it easier than ever to iterate quickly. The downside of rapid development is an increase in bugs and technical debt, making projects harder to manage without a proper testing solution. It is critical to have a comprehensive test suite to allow teams to test the API during development. 
 
->Stoplight makes it easy to create a full suite of tests by providing [Environment](/testing/using-variables/environment) and [Context variables](/testing/using-variables/context), and the ability to [reference other scenarios](/testing/referencing-other-scenarios/overview) to accelerate test generation and reduce duplication. 
+>Stoplight makes it easy to create a full suite of tests by providing [Environment](/testing/using-variables/environment) and [Context variables](/testing/using-variables/context), and the ability to reference other scenarios to accelerate test generation and reduce duplication. 
 
 ---
 **Related Articles**
-- [Passing Data Between Steps](/testing/getting-started/passing-data-between-steps)
 - [Running Tests In Stoplight](/testing/running-tests/in-stoplight)
 - [Running Tests in the Terminal](/testing/running-tests/in-the-terminal)
 - [Running Tests Triggered by URL](/testing/running-tests/triggering-by-url)
@@ -36,8 +35,7 @@ Microservices and serverless architecture have made it easier than ever to itera
 - [$$.env (Environment)](/testing/using-variables/environment)
 - [$.ctx(Context)](/testing/using-variables/context)
 - [Sending HTTP Requests](/testing/sending-http-requests/overview)
-- [Referencing other Scenarios](/testing/referencing-other-scenarios/overview)
-- [Contract Testing](testing/leveraging-openapi/contract-testing)
+- [Contract Testing](/testing/leveraging-openapi/contract-testing)
 - [Integrating in Continuous Integration](/testing/continuous-integration/overview)
 - [Integrating with Jenkins](/testing/continuous-integration/jenkins)
 - [Integrating with Travis](/testing/continuous-integration/travis)

articles/testing/run-test-stoplight.md

@@ -7,7 +7,7 @@ way is through the Stoplight editor.
 
 
 > If you haven't created your first scenario yet, please [do so before
-> continuing](testing/introduction)
+> continuing](/testing/introduction)
 
 Scenarios in Stoplight are composed of three different levels:
 

articles/testing/run-test-terminal.md

@@ -63,11 +63,11 @@ You can also run a contract test against a specific upstream URL with the
 prism validate --spec /path/to/my/spec.json --upstream http://localhost:8080
 ```
 
-For more information on contract testing and how it can be used, see [here](testing/leveraging-openapi/contract-testing).
+For more information on contract testing and how it can be used, see [here](/testing/leveraging-openapi/contract-testing).
 
 ---
 **Related Articles**
 
 - [Testing Introduction](/testing/introduction)
-- [Contract Testing](testing/leveraging-openapi/contract-testing)
+- [Contract Testing](/testing/leveraging-openapi/contract-testing)
 - [Integrating in Continuous Integration](/testing/continuous-integration/overview)

articles/testing/send-http-requests.md

@@ -110,7 +110,6 @@ platforms.
   ---
   **Related Articles**
 - [Testing Introduction](/testing/introduction)
-- [Passing Data Between Steps](/testing/getting-started/passing-data-between-steps)
 - [Running Tests In Stoplight](/testing/running-tests/in-stoplight)
 - [Running Tests in the Terminal](/testing/running-tests/in-the-terminal)
 - [Running Tests Triggered by URL](/testing/running-tests/triggering-by-url)

changelog-4-25-18.md

@@ -0,0 +1,19 @@
+# Stoplight v4.1.0 Release
+
+This update includes fair use billing, magic links, custom css, and more.
+
+## New 🚀
+
+- **[Fair Use Billing](https://docs.stoplight.io/platform/getting-started/billing)**: Our paid plans now only count active members that have created a project or updated project files in the past 30 days. This better aligns cost to value, and results in a lower bill in all cases. Now your members will only be added to your bill if and when they start creating content on Stoplight. Unleash your Engineers! 
+- **Annual Billing**: Save up to 20%.
+- **[Magic Invite Links](https://docs.stoplight.io/platform/organizations/invite-people)**: Share it via email, Slack, and other channels to easily onboard members in your organization. Fair use billing means they won’t count until they actually start creating content. Abra Kadabra. 
+- **[Custom CSS](https://docs.stoplight.io/documentation/design/custom-css)**: Add some custom style and flair to your documentation with Custom CSS. 
+- **Custom HTML Landing Pages**: Create beautiful custom landing pages to greet and direct your users. 
+- **[OAuth2 Token Generation in Hub’s Try it Out](https://docs.stoplight.io/documentation/oauth-hubs)**: If your API is protected by OAuth2, you can now generate tokens in the Try it Out block.
+
+## Enhancements 💪
+
+- **Relative $refs**: References from one file to another in the same project are now represented with relative URLs. For example, `./models/user.json` instead of `https://exporter.stoplight.io/45/master/models/user.json`. This has a number of benefits, such as increased portability. It also sets the stage for better desktop local file editing and versioning.
+- **Published hubs now support Internet Explorer 11**
+
+Please reach out via chat or support@stoplight.io if you have any questions about the above changes.