Developer 101 - Agility Platform Architecture

Agility Platform Architecture

Agility CMS is hosted in Azure: Microsoft’s Cloud Platform and managed 100% by the Agility product team. This consists of the following components:

  • Customer Databases: Where all of your content is stored securely in a scalable environment
  • Agility Content Server: The server responsible for synchronizing content to your websites
  • Agility Content Manager: Serves as a central point for configuring and managing content, as well as managing servers to which content is synchronized and other advanced settings specific to your Agility instance. This is often simply referred to Agility since this is the only public-facing component

Hosting Options

We offer load-balanced hosting in our Azure environment, however, you may optionally use a third-party private or cloud data center.

If you are hosting with us, you will have a Stage/UAT and Live server. If you are hosting on your own, it’s still highly recommended that you have a Stage/UAT and Live server so you can test your deployment on Stage/UAT before making any changes to Live.

Content Synchronization

Publishing content in the Content Manager triggers the synchronization process, sending a message to each active syncing web server. The web server(s) will receive the message and respond with a request to pull the published content from the Content Server. Upon receiving the content, a copy it is saved directly to the web server's file system. This means that the website has a copy all the content it needs, so there's never any real-time API requests or database calls. These are usually major bottlenecks in other CMS platforms.

Website Modes

An Agility website can be placed in one of two modes which can be controlled via the web.config:

  • Development Mode: Pulls the latest content (staging and published content) in real-time
  • Production Mode: When not in Development Mode, an Agility website can be viewed in a Preview Mode (only invoked by a secret hash passed into query strings for internal use) or Live Mode (public facing website).
    • Preview Mode: Pulls the latest content (staging and published content) in real-time
    • Live Mode: Content is pushed to each web server on publish by the Content Server

A typical Agility website will have a Stage/UAT and a Live server. Both Stage and Live should both NOT be in Development Mode. The idea here is to have two identical servers and website modes so you can test your code changes in a simulated live environment before deploying to Live.

Content States

All content in Agility has a State which will influence what appears on the live website, on preview, and what won’t appear at all. There are 3 States:

  • Staging: All new or edited content is placed in a Staging State. All content in Staging will be visible on Preview – it will not appear on the Live site unless it has been changed to a Published State. Published content which has been edited will stay in Staging until the latest changes are published. Staging includes several Sub-States designed for internal approval workflows and content scheduling.
    • Awaiting Approval: Types of content that has been previously defined to require approval needs to be approved before it can be Published
    • Approved: Content that has been approved, but not yet Published
    • Scheduled for Release: Content that has been scheduled to be automatically Published at a given date and time
  • Published: Content has been synchronized and is available to the live website
  • Unpublished: Content that has been either explicitly removed from the website either on demand or via Content Scheduling. Unpublished content will not appear in Preview or Live.
    • Expired: Content that has been scheduled to come down after a specific date and time


0 out of 0 found this helpful



Please sign in to leave a comment.