Using the Editor
Your Stelae WordPress is a full WordPress installation. Anything you can do in WordPress, you can do here. This page covers the things that are specific to Stelae.
Accessing Your WordPress
From your dashboard, click “Open Editor” on your site card. This opens your
private WordPress in a new tab. The URL is a random subdomain
(e.g. abc123.stelae.eu) — this is your editing URL, not your
public site URL.
Access is protected by a unique editor link that you can find on your site card in the dashboard. Share this link with anyone who should be able to edit the site. You can regenerate the link at any time from the dashboard, which immediately invalidates the old one.
Themes
You can install and use any WordPress theme. All visual output — HTML, CSS, JavaScript, fonts, images — is captured during export. The theme’s PHP code runs only during editing and export; it’s never exposed to visitors.
A few tips for choosing themes that work well with static export:
- Prefer themes that render content at build time. Most modern themes do this by default. If a theme shows all content when you preview a page in WordPress, it will survive the export.
-
Be cautious with themes that lazy-load content via AJAX. Some themes
load content by making requests to
admin-ajax.phpor the WP REST API when the page loads in the browser. This content won’t be available on the static site because there’s no WordPress backend running. You can usually spot this by viewing a page’s source — if content sections are empty in the HTML and filled in by JavaScript, that content relies on AJAX. - Block themes (Full Site Editing) work well. They render everything as HTML in the page source.
Plugins
You can install any WordPress plugin, but only plugins whose output is baked into the HTML will have visible effects on the static site. See the compatibility guide for a detailed breakdown.
The short version:
- Visual plugins (Elementor, Beaver Builder, Gutenberg blocks, etc.) — work perfectly.
- SEO plugins (Yoast, Rank Math, etc.) — work perfectly. Meta tags, sitemaps, and structured data are all generated at build time.
- Form plugins (Contact Form 7, WPForms, Gravity Forms) — will not work. The forms will render visually but submissions have nowhere to go. Use a third-party form service instead.
- Caching plugins — unnecessary. Your live site is already static.
- Security plugins — unnecessary for the live site (there’s no PHP or database to attack). May be useful inside the editor to limit login attempts.
Stelae installs a must-use plugin (mu-plugin) in your WordPress that handles
the static export trigger and pretty permalink setup. Do not remove or modify files in
wp-content/mu-plugins/ — they’re mounted read-only.
Page Builders
Page builders generate their output as HTML and CSS, which is exactly what the export captures. Elementor, Beaver Builder, Bricks, GenerateBlocks, WPBakery, Divi — all produce static output that exports cleanly.
One caveat: some page builders (notably WPBakery/Visual Composer) load certain
content via AJAX calls to admin-ajax.php. Content loaded this way
won’t appear on the static site. If you notice empty sections after export,
this is likely the cause. Check the
troubleshooting guide for how to
diagnose this.
Media and Uploads
Upload images, videos, PDFs, and other media through the WordPress media library as normal. All media files are included in the static export archive.
Keep in mind that your container has a disk quota. Large media libraries (hundreds of high-resolution images) will consume disk space. Optimize images before uploading where practical — this also makes your static site load faster for visitors.
Permalinks
Stelae automatically sets your permalink structure to /%postname%/
(pretty permalinks) when your site is provisioned. This is important because
query-string URLs like ?page_id=2 don’t work on most static hosts.
If you change your permalink structure in WordPress settings, the export will use
whatever structure is currently active. Stick with /%postname%/ unless
you have a specific reason to change it.
Container Lifecycle
Your WordPress container is a real Docker container with allocated CPU, memory, and disk resources. To keep costs low and density high, containers follow a sleep/wake lifecycle:
- Running: Your container is active and you can access WordPress normally.
- Sleeping: After 15 minutes of inactivity (no HTTP requests), the container is stopped. It uses zero CPU and minimal disk.
- Waking up: When you access your editor URL, the container starts automatically. This takes about 5 seconds.
Your WordPress files, database, themes, plugins, and uploads are all preserved across sleep/wake cycles. Nothing is lost when the container sleeps.