Restricting access via Basic Authentication

Basic Authentication is the “pop up” prompt for a username and password which is displayed by your browser when you visit a site which is protected in this way.

While a site is under development, and for non-production sites, you can set up Basic Authentication via your VIP Dashboard.

It is not possible for launched production sites to use Basic Authentication, as this form of access control breaks various VIP Go platform services.




To enable Basic Authentication in the VIP Dashboard by visiting the Settings -> Basic Authentication -> Configure.

Select the desired environment from the dropdown, e.g. “production” or “develop.” Enter the username and password information for any user who should have access to your app via Basic Authentication. The password you enter will be encrypted when stored; you do not need to enter an encrypted version of the password. If you are using a multisite WordPress install, the Basic Authentication restrictions you create will apply to all subsites.

Once you’ve added credentials, you can remove them from the site by deleting the users. To completely remove all Basic Authentication restrictions, remove all users.

Removing a user from basic auth

Restricting access via an IP Allow List

Using the IP Allow List you can limit access to each application environment to a specified list of IP addresses or ranges of IP addresses (aka subnets). Once you have applied the IP Allow List to an environment, any and all requests from an IP address list outside of the allowed list or range will be denied.

The IP Allow List applies to all requests:

  • Requests from logged in and anonymous users
  • Requests for files
  • Requests for a WordPress or Node application
  • Cached and uncached requests

The only exception is services within Automattic’s networks, as these will need access to support the operation of your application.

You control the IP Allow List separately for each environment of your application, e.g. the production environment has a separately controlled IP Allow List to the develop environment.

Viewing and controlling your IP Allow List

The IP Allow List for an environment is controlled from your VIP Dashboard. Anyone with access to the VIP Dashboard for your application can view the IP Allow List. Only users with write or admin roles on the GitHub repository for your application are authorized to add and remove IP addresses and ranges for your application environments. The UI for the IP Allow List is shown below:

IP allow list UI

To view the IP Allow List:

  1. Visit the VIP Dashboard
  2. Select the application from the list of applications that you have access to
  3. From the left hand menu for that application, choose “Settings”
  4. At the top of the “Settings” screen choose the environment you want to configure, e.g. “Production”, “Develop”, etc
  5. From the “IP Allow List” section, choose “Configure”

If your IP Allow List is configured, you will be able to see the details here.

If your IP Allow List isn’t configured, you will see a notice saying “No IP addresses have been added. Your site is accessible to everyone.

To add an IP or subnet (aka CIDR range, aka IP range) select the round “+” button top right and follow the directions. Adding the first IP address will immediately deny access from all other IP addresses. You can add a list of IP addresses separated by commas.

To remove an IP or subnet, select the “trash” (delete) icon to the right of the IP or subnet. Removing the last IP or subnet will make the environment accessible from anywhere on the internet.


  • Changes will take up to five minutes to take effect
  • A 403 Forbidden error is what you’ll get when trying to visit your app from an IP not on the IP Allow List
  • Amending the IP Allow List logs an event in our internal audit log

Two-factor Authentication on VIP Go

Two-factor authentication (also known as multi-factor authentication and 2fa) is a method of securing accounts which requires a user to know something (e.g. a password) but also that you possess something (e.g. your mobile device). This method of requiring multiple forms of verification is an easy to way to protect your sites against common account breaches due to leaked or guessed passwords. Two-factor authentication is integrated with all WordPress sites on the VIP Platform and easy to use and enforce.

Enabling Two-Factor Authentication

If you have a WordPress account, to enable Two-factor authentication, just visit Users > Your Profile and enable your preferred authentication methods in the Two-Factor Options section.

Enforcing Two-factor Authentication

Two-factor authentication is required on VIP Go for all administrators and custom roles with the manage_options capability. If you’d like to force two factor authentication for other roles, you can use the wpcom_vip_is_two_factor_forced filter. For example, to enable for all users that can edit posts:

add_action( 'set_current_user', function() { 
    $limited = current_user_can( 'edit_posts' );
    add_filter( 'wpcom_vip_is_two_factor_forced', function() use ( $limited ) {
        return $limited;
    }, PHP_INT_MAX );
} );

Or, to enable for all users on the site:

add_filter( 'wpcom_vip_is_two_factor_forced', '__return_true' );

Disable Two-factor Authentication Enforcement

If you’re using an external auth provider that already enforces two-factor authentication, you can choose disable enforcement for users on the site. You can add this to a file inside your client-mu-plugins folder. (Note that with this snippet, the built-in two factor options will still be available to users).

add_filter( 'wpcom_vip_is_two_factor_forced', '__return_false' );

If you’d like to remove the built-in Two-factor options completely, you can add the following snippet to a file inside your client-mu-plugins folder:

add_filter( 'wpcom_vip_enable_two_factor', '__return_false' );

Note: These filters will not work properly if placed in the theme.

Resetting Two-Factor Authentication for Locked Out Users

There are two primary methods available for both admin and super admin user roles to disable two-factor authentication for users that are locked out of their account.

Prior to disabling two-factor authentication, we highly recommend confirming that the user has indeed lost access to their account. Since emails can be faked, we recommend confirming with the individual in person or over the phone.

To disable two-factor authentication, you can do either of the following from the Dashboard under Users > Edit > Two-Factor Options:

  • Deselect all available two-factor methods. This will allow the user to login without needing any additional code.
  • Enable the Backup Codes option. Then, you can send a backup code to the user that they can use to login to their account.

Once the user regains access to the account, they can adjust any two-factor settings to prevent losing access moving forward (reset phone number, for example). We also recommend having them print out backup codes to prevent future lockouts.

Validating, sanitizing, and escaping

Your code works, but is it safe? When writing your theme and plugin code, you’ll need to be extra cautious of how you handle data coming into WordPress and how it’s presented to the end user. This commonly comes up when building a settings page for your theme, creating and manipulating shortcodes, or saving and rendering extra data associated with a post. There is a distinction between how input and output are managed, and this document will walk you through that.

(If you’re interested in more thoughts on why VIP takes these practices so seriously, read The Importance of Escaping All The Things from June 2014.)

Guiding Principles

  1. Never trust user input.
  2. Escape as late as possible.
  3. Escape everything from untrusted sources (like databases and users), third-parties (like Twitter), etc.
  4. Never assume anything.
  5. Never trust user input.
  6. Sanitation is okay, but validation/rejection is better.
  7. Never trust user input.

“Escaping isn’t only about protecting from bad guys. It’s just making our software durable. Against random bad input, against malicious input, or against bad weather.”

Validating: Checking User Input

To validate is to ensure the data you’ve requested of the user matches what they’ve submitted. There are several core methods you can use for input validation; usage obviously depends on the type of fields you’d like to validate. Let’s take a look at an example.

Say we have an input area in our form like this:

<input id="my-zipcode" type="text" maxlength="5" name="my-zipcode" />

Just like that, we’ve limited my user to five characters of input, but there’s no limitation on what they can input. They could enter “11221” or “eval(“. If we’re saving to the database, there’s no way we want to give the user unrestricted write access.

This is where validation plays a role. When processing the form, we’ll write code to check each field for its proper data type. If it’s not of the proper data type, we’ll discard it. For instance, to check “my-zipcode” field, we might do something like this:

$safe_zipcode = intval( $_POST['my-zipcode'] );
if ( ! $safe_zipcode )
$safe_zipcode = '';
update_post_meta( $post->ID, 'my_zipcode', $safe_zipcode );

The intval() function casts user input as an integer, and defaults to zero if the input was a non-numeric value. We then check to see if the value ended up as zero. If it did, we’ll save an empty value to the database. Otherwise, we’ll save the properly validated zipcode.

Note that we could go even further and make sure the the zip code is actually a valid one based on ranges and lengths we expect (e.g. 111111111 is not a valid zip code but would be saved fine with the function above).

This style of validation most closely follows WordPress’ safelist philosophy: only allow the user to input what you’re expecting. Luckily, there’s a number of handy helper functions you can use for most data types.

Sanitizing: Cleaning User Input

Sanitization is a bit more liberal of an approach to accepting user data. We can fall back to using these methods when there’s a range of acceptable input.

For instance, if we had a form field like this:

<input id="title" type="text" name="title" />

We could sanitize the data with the sanitize_text_field() function:

$title = sanitize_text_field( $_POST['title'] );
update_post_meta( $post->ID, 'title', $title );

Behind the scenes, the function does the following:

  • Checks for invalid UTF-8
  • Converts single < characters to entity
  • Strips all tags
  • Remove line breaks, tabs and extra whitespace
  • Strip octets

The sanitize_*() class of helper functions are super nice for us, as they ensure we’re ending up with safe data and require minimal effort on our part.

In some instances, using wp_kses and it’s related functions might be a good idea as you can easily clean HTML while keeping anything relevant to your needs present.

Escaping: Securing Output

For security on the other end of the spectrum, we have escaping. To escape is to take the data you may already have and help secure it prior to rendering it for the end user. WordPress thankfully has a few helper functions we can use for most of what we’ll commonly need to do:

esc_html() we should use anytime our HTML element encloses a section of data we’re outputting.

<h4><?php echo esc_html( $title ); ?></h4>

esc_url() should be used on all URLs, including those in the ‘src’ and ‘href’ attributes of an HTML element.

<img alt="" src="<?php echo esc_url( $great_user_picture_url ); ?>" />

esc_js() is intended for inline Javascript.

<div onclick='<?php echo esc_js( $value ); ?>' />

esc_attr() can be used on everything else that’s printed into an HTML element’s attribute.

<ul class="<?php echo esc_attr( $stored_class ); ?>">

wp_kses() can be used on everything that is expected to contain HTML.  There are several variants of the main function, each featuring a different list of built-in defaults.  A popular example is wp_kses_post(), which allows all markup normally permitted in posts. You can of course roll your own filter by using wp_kses() directly.

<?php echo wp_kses_post( $partial_html ); echo wp_kses( $another_partial_html , array( 'a' => array(
        'href' => array(),
        'title' => array()
    'br' => array(),
    'em' => array(),
    'strong' => array(),
);) ?>

As an example, passing an array to wp_kses() containing the member

'a' => array( 'href' , 'title', )

means that only those 2 HTML attributes will be allowed for a tags — all the other ones will be stripped. Referencing a blank array from any given key means that no attributes are allowed for that element and they should all be stripped.

There has historically been a perception that wp_kses() is slow. While it is a bit slower than the other escaping functions, the difference is minimal and does not have as much of an impact as most slow queries or uncached functions would.

It’s important to note that most WordPress functions properly prepare the data for output, and you don’t need to escape again.

<h4><?php the_title(); ?></h4>

rawurlencode() should be used over urlencode() for ensure URLs are correctly encoded. Only legacy systems should use urlencode()`.

<?php echo esc_url( '' . rawurlencode( $stored_class ) ); ?>

Always Escape Late

It’s best to do the output escaping as late as possible, ideally as data is being outputted.

// Okay, but not that great
$url = esc_url( $url );
$text = esc_html( $text );
echo '<a href="'. $url . '">' . $text . '</a>';

// Much better!
echo '<a href="'. esc_url( $url ) . '">' . esc_html( $text ) . '</a>';

This is for a few reasons:

  • It makes our code reviews and deploys happen faster because rather than hunting through many lines of code, we can glance at it and know it’s safe for output.
  • Something could inadvertently change the variable between when it was firstly cast and when it’s outputted, introducing a potential vulnerability.
  • Future changes could refactor the code significantly. We review code under the assumption that everything is being output escaped/cast – if it’s not and some changes go through that make it no longer safe to output, we may incorrectly allow the code through, since we’re assuming it’s being properly handled on output.
  • Late escaping makes it easier for us to do automatic code scanning (saving us time and cutting down on review/deploy times) – something we’ll be doing more of in the future.
  • Escaping/casting on output simply removes any ambiguity and adds clarity (always develop for the maintainer).

Escape on String Creation

It is sometimes not practical to escape late. In a few rare circumstances you cannot pass the output to wp_kses since by definition it would strip the scripts that are being generated.

In situations like this always escape while creating the string and store the value in a variable that is a postfixed with _escaped, _safe or _clean. So instead of $variable do $variable_escaped or $variable_safe.

If a function cannot output internally and late escape, then it must always return “safe” html, that does not rely on them being late escaped. This allows you to do echo my_custom_script_code(); without needing the script tag to be passed through a version of wp_kses that would allow such tags.

Case Studies and FAQs

We know that validating, sanitizing and escaping can be a complex topic; we’ll add some specific case studies and frequently asked questions here as we think they might be helpful.

Q: Doesn’t a function like WP_Query handle sanitizing user input before running a query for me? Why do I need to also sanitize what I send to it?

A: For maximum security, we don’t want to rely on WP_Query to sanitize our data and hope that there are no bugs or unexpected interactions there now or in the future. It’s a good practice to sanitize anything coming from user-land as soon as you begin to interact with it, treating it as potentially malicious right away.

Q: Isn’t WP_KSES_* slow?
A: Even on large strings WP_KSES_* will not add a significant overhead to your pageload. Most of your pageloads should be cached pageloads and the first thing to focus on should be to make sure as many of your end users as possible are getting cached pages. Slow SQL Queries as well as Remote requests are often next on the list. Escaping is often negligible compared to those items.

Zack Tollman wanted to know more about wp_kses functions, so he did a pretty thorough investigation about them here. He found that wp_kses functions can be 20-40x slower than esc_* functions on PHP 5.6, but the performance hit is much smaller when using HHVM. The post was written before PHP 7 came out, but PHP 7 is likely to have similar performance to HHVM, meaning that wp_kses functions aren’t as much as a performance drain as they used to be, at least on PHP 7 servers. is using PHP 7.

Q: Why do I need to escape these values? It is impossible for them to be unsafe.
A: It is currently impossible for them to be unsafe. But a later code change could easily make it that the variable is modified and therefore can no longer be trusted. Always late escaping whenever possible makes the code much more robust and future proof.


To recap: Follow the safelist philosophy with data validation, and only allow the user to input data of your expected type. If it’s not the proper type, discard it. When you have a range of data that can be entered, make sure you sanitize it. Escape data as much and as late as possible on output to avoid XSS and malformed HTML.

Take a look through the Data Validation Plugin Handbook page  to see all of the sanitization and escaping functions WordPress has to offer.

Restricting access to a site hosted on VIP Go

There are many different ways to restrict access to your applications and environments on VIP Go. Here, we review the various techniques available. Note: the IP Allow List and Basic Authentication access restriction methods cannot both be active at the same time. If you attempt to activate them both, Basic Authentication will take precedence.

Techniques for Restricting Access

Restricting by IP (Full Site)

When and how to use: If you want to completely restrict access to the entire site to a defined list or range of IP addresses (i.e. subnets) for your team, use the IP Allow List feature. Common implementations are for sites with highly sensitive content, intranets, and non-production environments.

What is restricted: Once enabled, any requests from IP addresses outside of the allowed range will be rejected with a 403 response from our CDN.

The restriction applies to all requests to the environment: cached and uncached requests, static files, media files, and dynamically generated content.

Content is also blocked from Jetpack’s content distribution tools. To change this behavior, please see “Controlling Content Distribution via Jetpack”.

Considerations: For added protection, you can also require all users to log in before accessing the site (see “Restricting via Authentication (Full Site)” below).

Restricting by IP (Partial Site)

When and how to use: If you want to restrict access to certain parts of the site (e.g. WordPress Admin) to a defined list or range of IP addresses, you can do so at the application level.

For this to work, users must be logged in to access the restricted portions of the site. This is to avoid the caching and leaking of restricted content.

To enforce this, hook into the WordPress login flow and all subsequent logged in requests, and reject access if the user is not visiting from an authorized IP address.

What is restricted: Since the restrictions are implemented at the application level (i.e. your code), you have full control over which WordPress content and pages should be restricted.

Please note that the restrictions will only apply to content generated by WordPress–media and static assets will continue to be publicly accessible.

Content will also continue to be syndicated via Jetpack’s content distribution tools. To change this behavior, please see “Controlling Content Distribution via Jetpack”.

Considerations: In order for the VIP team to support your site, any IP enforcements at the application level should allow requests from our network. This can be done by checking for and allowing requests when true === A8C_PROXIED_REQUEST – you can use the utility function is_proxied_request().

Restricting via Basic Auth (Full Site)

When and how to use: If you want to restrict access to the entire site in the form of a username/password challenge, you can use our Basic Auth feature.

This is useful when you do not have a static list or range of IP addresses for your team. Common uses for Basic Auth are non-production/test environments and pre-launch production environments that are under development.

What is restricted: Once enabled, any requests without the proper username and password combination will be rejected.

The restriction applies to all requests to the environment: cached and uncached requests, static files, media files, and dynamically generated content.

Content is also blocked from Jetpack’s content distribution tools. To change this behavior, please see “Controlling Content Distribution via Jetpack”.

Restricting via Authentication (Full Site)

When and how to use: If you want to restrict access to authenticated users only, you can use one of the many WordPress plugins that support this functionality like Force Login or Registered Users Only. If your organization has a Single Sign On (SSO) system, you can simplify the login process for your team by integrating it into the login flow.

What is restricted: Once enabled, logged out users would be required to login and verify permissions before being able to access the site.

Please note that the restrictions will only apply to content generated by WordPress. Media and static assets will continue to be publicly accessible.

Content will also continue to be syndicated via Jetpack’s content distribution tools. To change this behavior, please see “Controlling Content Distribution via Jetpack”.

Restricting via Authentication (Temporary)

When and how to use: If you want to temporarily restrict access to a site (e.g. site under development or for pre-launch configuration), you can use the Maintenance Mode plugin.

What is restricted: After installing and configuring the plugin, only users with Author-level access and above can access the site.

Please note that the restrictions will only apply to content generated by WordPress. Media and static assets will continue to be publicly accessible.

Content will also continue to be syndicated via Jetpack’s content distribution tools. To change this behavior, please see “Controlling Content Distribution via Jetpack”.

Controlling Content Distribution via Jetpack

Jetpack adds a suite of powerful security, performance, and marketing tools to all VIP sites, including various tools to aid in content consumption, distribution, and syndication. These include:

For sites with restricted access, you may want to change the behavior of these tools depending on your specific use cases.

Enabling Content Distribution

For sites that rely on IP Allow List or Basic Auth to restrict access, we automatically disable Jetpack’s content distribution tools. This means that content is blocked from being:

  • Accessed via the REST API or Jetpack Search via unauthenticated requests;
  • Consumed via the Reader; and
  • Syndicated via the Firehose.

If you would prefer to leave your site restricted but will still like your content to be distributed via Jetpack, you can add the following code snippet to your vip-config.php file:

if ( ! defined( 'VIP_JETPACK_IS_PRIVATE' ) ) {
define( 'VIP_JETPACK_IS_PRIVATE', false );

Within 30 minutes, the default content distribution features that are included with Jetpack will be restored

If you would like to fine-tune which content distribution features are enabled, you can do so using the jetpack_get_available_modules filter.

Disabling Content Distribution

For sites that rely on restricting access via plugins or mechanisms that aren’t native to the VIP Platform (like paywalls), you may want to restrict content distribution via Jetpack.

To do so, you can add the following code snippet to your vip-config.php file:

if ( ! defined( 'VIP_JETPACK_IS_PRIVATE' ) ) {
define( 'VIP_JETPACK_IS_PRIVATE', true );

To restrict content distribution for select subsites in a Multisite, you can do that by targeting the subsite. Here is an example for a Subdomain Multisite:

if ( '' === $_SERVER['HTTP_HOST'] ) {
    define( 'VIP_JETPACK_IS_PRIVATE', true );

or for a Subfolder Multisite

if ( '' === $_SERVER['HTTP_HOST'] && 0 === strpos( $_SERVER['REQUEST_URI'], '/subsite/' ) ) {
    define( 'VIP_JETPACK_IS_PRIVATE', true );

Within 30 minutes, content will no longer be accessible via Jetpack’s default content distribution features.

Please note, disabling Jetpack Content Distribution will block content from being accessible through the Jetpack Search API. Therefore, WordPress will fall back to its standard database search. You can configure Jetpack Search to make content accessible via authenticated requests by using the snippet provided in our documentation to your client-mu-plugins directory. You’ll also want to make sure that Jetpack Search is activated within your codebase.

Non-production Environments

Any applications created after August 28, 2020 (with new GitHub repos) will have Content Distribution disabled by default in their non-production environments.

If you’d like to keep Content Distribution enabled for these environments or tweak their behavior, please follow instructions in the sections above.

SSL for VIP Go sites

A VIP Go site must have an SSL certificate installed in order to be active. Because every site uses a custom domain for both the front-end and admin area, and because we want each site to have a secure admin area and login process at minimum, SSL is a requirement.

Note that our SSL implementation is SNI based, which means some legacy browsers will not be fully supported in their access to pages served over SSL.

Setup process

By default, the VIP team will handle the procurement, installation and renewal of SSL certificates for all VIP Go sites, beginning with the initial site setup process. We procure and install certificates from Let’s Encrypt, which provides efficient and automated methods to do so.

If you would like to provide your own SSL certificate, please note this during the initial site planning conversations, and open a support ticket noting this during the site setup process. The steps from there include:

  • The VIP team will provide you with a CSR to use in obtaining a certificate.
  • You can obtain the certificate from a certificate authority of your choosing. The certificate needs to include both “www” and the root version of a hostname, so a SAN or wildcard certificate is probably best.
  • Deliver the certificate to us via support ticket. If you want to also provide a private key, please contact us for notes on how to do this securely; please do not attach a private key to a support ticket or regular email message.
  • The VIP team will install the SSL certificate and confirm that it is working as expected.

HTTPS redirection

Whole-site HTTPS is enabled for all sites by default. This means all front-end and all admin traffic requesting the site over an insecure HTTP protocol will be redirected to HTTPS.

If another mode of HTTPS is required, please let VIP know as soon as possible. These modes are available:

  1. HTTPS Admin/Dual Frontend – Redirect all admin area traffic to HTTPS, but allow HTTP or HTTPS traffic for the front end. If you require certain URLs within your site to be HTTPS only, for example, a checkout or donations page, then you can apply the appropriate redirections in WordPress theme or plugin code.
  2. HTTPS Admin/HTTP Frontend – Redirect all admin area to HTTPS, and redirect all front end traffic to HTTP.

HTTP Strict Transport Security

VIP Go supports and strongly encourages the use of HTTP Strict Transport Security (HSTS) headers, which declares to supporting web browsers that a website is accessible only over an HTTPS connection. HSTS headers are an important security measure as they prevent person-in-the-middle attacks, protocol downgrade attacks, and cookie hijacking. When HSTS is activated, it adds the max-age=31536000 (or a lower number if needed) header. The preload and includeSubDomains options are also available.

Please be aware that if you configure HSTS headers for your site and then revert the site back to responding over HTTP only, any previous visitors will effectively be blocked from accessing your site as their browser will not allow HTTP requests to be made. This is not a bug; this is how HSTS is designed to work.

If you would like your site to be configured for HSTS, please open a support ticket.

Non-production sites on VIP Go

Non-production sites on VIP Go can use a subdomain of the or convenience subdomain, which is covered by a wildcard SSL certificate. All sites using this convenience subdomain are set to the “whole-site HTTPS” option described above, with all HTTP traffic being redirected to HTTPS; this cannot be changed.

Please note that sub-subdomains of the convenience domain are not currently supported.

User security best practices

We encourage all users on VIP sites to follow best practices when it comes to securing their devices, accounts and access to VIP tools. Two-factor authentication is required for all users with the ability to publish to a VIP site and we also recommend following at least these basic steps:

  1. Set a login password for all user accounts on your computer.
  2. Set a complex (more than 4 character) passcode to unlock your mobile devices. Do not use fingerprints or patterns.
  3. Enable a screen saver that activates after a short period of time and requires a password to turn off.
  4. Use only strong passwords. Never use the same password in more than one place.
  5. Use a password manager such as 1Password or LastPass.
  6. Never put passwords in text documents, Google Docs, intranet pages, post-it notes or other unencrypted forms of storage.
  7. Use two-factor authentication for any services that support it, including accounts, Google apps such as Gmail, Dropbox, Twitter, Facebook, Github, iCloud, LinkedIn, PayPal and others. Do not store 2FA backup codes anywhere online. We strongly recommend using an authenticator app, such as Authy or Google Authenticator, over SMS-based two-factor authentication.
  8. Turn on device locating services such as “Find My Mac” for Apple laptops or “Find My iPhone” for iPhones.
  9. Encrypt your computer’s hard drive, and make sure any backups are encrypted too.
  10. Install and run anti-virus software with the latest virus definitions.
  11. Enable your computer’s firewall.
  12. Ensure that your home and office network routers are running the latest firmware and aren’t using default passwords.
  13. Be suspicious of any unusual requests to share sensitive information, such as usernames, passwords or other personal data. Report any such requests and “phishing” attempts.
  14. If working in public, use a privacy screen to prevent your activity being seen.

If you have any security-related questions about your account, your VIP site or any related service, please contact us via support ticket.

Ready to get started?

Drop us a note.

No matter where you are in the planning process, we’re happy to help, and we’re actual humans here on the other side of the form. 👋 We’re here to discuss your challenges and plans, evaluate your existing resources or a potential partner, or even make some initial recommendations. And, of course, we’re here to help any time you’re in the market for some robust WordPress awesomeness.

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.