Secure Dev Server

[fweth]

Body

Summary

A secure dev-like preview server, which is safe to broadcast for limited preview functionality

Background & Motivation

When implementing a CMS into an SSG Astro site (webhook triggered build), the clients often want a live preview of their changes. Apparently it's not safe to broadcast the dev server. However, when using the SSR adapter (activated via env variable), the whole site must be built with SSR in mind, and some convenience is lost, like returning data from getStaticPaths.

Goals

Basically just a version of the dev server which is secure to broadcast (optimization is not important, the editors don't care if page reload takes 5 or 500 ms). Functionality wise, exactly what the dev server is currently doing.

However, a very cool extra feature would be auto reload triggered from webhook, but that's totally optional.

Example

Run npm run preview-dev (not an ideal name, but npm run preview is already taken) on the preview server (typically a small cloud instance) with an open port.

[delucis]

I guess this is potentially a duplicate of #564?

[fweth]

@delucis yes, in a way! Although I don't ask for concurrent previews, I assume this would complicate the matter. More importantly, I don't ask for a preview mode in the (SSG/SSR) build, if I understand that other RFC correctly ("Support for a preview mode of your Astro build"), I'd run the preview on a different URL from a different server (typically a very small cloud instance).

In my case, the production domain is purely statically hosted and doesn't run on a Node server, so having a preview mode there would be impossible.

I'd be happy with a sandboxed dev server or something similar, no additional functionality needed, just make it secure (so that no FS access is possible).

[delucis]

On thing you could do is deploy your non-static preview server something like this:

// astro.config.mjs

// Node as an example, but could be a different adapter instead.
import adapter from '@astrojs/node';
import { defineConfig } from 'astro/config';

export default defineConfig({
  ...(process.env.PREVIEW_SERVER ? {
    output: 'server',
    adapter,
  } : {}),
  // other Astro config
});

Then in your preview deployment you’d set a PREVIEW_SERVER environment variable to enable building it as an on-demand site instead of a static site.

[fweth]

Yes, that works fine, but as I wrote above, you lose some nice features, like returning data from getStaticProps. In other words, you need to build the site SSR-ready, while the dev server is able to work with all types of sites.