Skip to main content
Warning This document has not been updated for a while now. It may be out of date.
Last updated: 3 Aug 2020

How the draft stack works

The “draft stack” on GOV.UK, is intended to be a full version of GOV.UK that includes content that has not yet been sent for publication. This allows content editors to preview their content before making it live, without having to manually copy it into a separate version of the publishing tool.

Content Preview contains most frontend applications.

Content Preview exists in each of integration, staging and production.


Content Preview consists of separate ‘draft’ instances of the router, frontend and content-store machines. These are located at draft-cache-{1,2}.router, draft-frontend-{1,2}.frontend, and draft-content-store-{1,2}.api respectively.

Publishing tools send content to the publishing-api. All content is initially pushed to the draft content store, and then to the live content store when it is published.

The draft-frontend and draft-cache machines host draft instances of the frontend apps and router which serve the content from the draft content-store. Both router and content-store share MongoDB clusters with their respective live versions, although they use separate databases on these clusters.

Because draft involves content-store apps only, there are no instances of MySQL or PostgreSQL in Content Preview, and no backend apps (except for router-api).


Content Preview is available in all three environments.


Because Whitehall permits content to be access-limited before publication, the draft environment enforces Signon authentication for all routes. This is performed by the authenticating-proxy app, which sits between Varnish and the router.

Draft content items can contain an optional access_limited hash in their metadata, which contains a list of Signon user UIDs corresponding to the users who are permitted to see that content. All other users will see a 403 Forbidden page.

(This is achieved by the API adapters passing the UID in the headers of the request to content-store, in the same way as the govuk-request-id.)

Publishing apps can also add an auth_bypass_ids list to the access limited hash, to allow unauthenticated access for preview or fact checking. The ID is encoded in a JSON Web Token and appended to the URL provided to the users. Authenticating-proxy decodes the token and extracts the ID, and again passes it to the content-store in the request headers, where it is compared with the ID stored on the requested content item.

Publishing API strips out the access_limited hash before sending data to the live content-store, since all published content is viewable by everyone.