Frequently asked questions

Currently, Webstudio's CLI export generates compiled output that isn't easily readable or editable due to lack of component separation. While you can export static sites and publish them outside of Webstudio Cloud, the code isn't optimized for manual editing. For AI-powered website generation and editing, Webstudio is developing a separate tool called Inception (webstudio.is/inception) for design exploration, while maintaining Webstudio as a precision tool for professional development.

You don't need to delete the default .wstd.io domain. Think of it as a 'staging server' where you can deploy and test without your site going live and without being indexed by search engines. These domains will always exist, you don't need to publish to them, and they won't be indexed by search engines.

Yes, Webstudio can be self-hosted using Docker. However, the documentation for Docker setup is currently limited. You can find some guidance in the contributing docs for developers section. Note that some features like email sending are cloud-only, so you'll need to implement your own backend solutions for features like webhook forms when self-hosting.

The default .wstd.io domains are not indexed by search engines as they're meant to be development domains. If you want extra protection, you can check 'exclude from search' in all page settings. For additional security, you can add robots.txt file or meta tags like <meta name="robots" content="noindex,nofollow,noarchive">. If using Cloudflare, you can also add password protection. You don't need to delete the project - think of the .wstd.io domain as a staging server where you can test without affecting your live site.

To migrate a self-hosted Webstudio instance:

1. Run 'pnpm migrations migrate' to update the database schema,
2. Ensure your Docker volumes are properly mapped to preserve data,
3. Check that the old volumes are still in use with 'docker cli' commands rather than relying on GUI interfaces. Always verify your volume mappings before and after updates to prevent data loss.

To migrate or update a self-hosted Webstudio instance, run the migrations command: pnpm migrations migrate. This should handle database migrations and updates when moving to a new version. When updating Docker containers, the system should continue using existing volumes and data. If you encounter issues where it appears that old volumes aren't being used, check with Docker CLI commands rather than relying on GUI tools, as the command line often provides more accurate information about volume usage. Always backup your data before performing migrations, and test the migration process in a development environment first.

For self-hosted builder migrations, run 'pnpm migrations migrate' to update the database schema. Docker volumes should persist between updates, so your data should remain intact when updating to newer versions.

The default .wstd.io domains are not indexed by search engines as they're meant to be development domains. If you want extra protection, you can check 'exclude from search' in all page settings. For additional security, you can add robots.txt file or meta tags like <meta name="robots" content="noindex,nofollow,noarchive">. If using Cloudflare, you can also add password protection.

Webstudio can be self-hosted using Docker, but documentation is currently limited. You can find some guidance in the contributing docs for developers section. Be aware that some features like email sending are cloud-only, so you'll need to implement your own backend solutions for features like webhook forms when self-hosting. The Docker container images are available on GitHub Packages, but setting up the required environment variables may require some investigation.

When setting up Webstudio locally, if you encounter issues with TRPC tokens needed for the publishing flow and static build export, you can bypass this by using the Webstudio CLI directly instead of going through the internal publishing flow. The CLI provides a more straightforward way to export your projects without dealing with internal authentication tokens.

Unfortunately, you cannot use the Webstudio CLI without publishing first. The build is created when you publish and is needed to get synced via CLI. If you want privacy for your wstd.io domain, consider self-hosting the Webstudio builder (not just the site) to use Pro features without cloud publishing requirements.

If Webstudio appears to be down or you can't open projects, first try refreshing the page. If the issue persists, it may be due to a deployment issue which the team typically resolves quickly. You can check the Discord community for status updates or report the issue. Webstudio has fast response times for service interruptions.

If your domain shows as 'Active, but not published' and the publish button is grayed out, you likely need to add the required 'Built with Webstudio' badge to your site. On the free plan, you can use one custom domain but must include this badge on your website.

If your domain shows 'Active' but the publish button is greyed out, you likely need to add the required 'Built with Webstudio' badge to your site. For free accounts, this badge is mandatory when using custom domains. Add the badge component to your site, and the publish button should become available. Pro accounts can remove this badge requirement.

When your custom domain shows 'Active, but not published' with a grayed-out publish button, it's usually because you haven't added the required 'Built with Webstudio' badge to your website. In the free version, you can use one custom domain, but it must include the Webstudio badge. You need to manually add this badge component to your site before you can publish to a custom domain.

Your DNS provider likely lacks CNAME flattening at the apex. Adding 'www' ensures reliable CNAME mapping without breaking other records (email, etc.). To use the root cleanly, switch nameservers to a provider (e.g. Cloudflare) that supports flattening.

Root domain setup is non-standard and broken with some providers like Namecheap. It can break other services connected to your domain (like email). The solution is to use CNAME flattening by migrating your domain to Cloudflare nameservers, which properly supports root domain hosting and gives you additional options and protection.

If WordPress CMS content works in the editor but not on the live site, try enabling 'client only' for all scripts in your project settings. This forces scripts to run on the client side rather than server-side, which can resolve content loading issues. Also check for any 404 errors in the browser console that might indicate routing or API access problems.

If the publish button is disabled after adding a custom domain, check for error messages displayed in red text in the domain configuration dialog. Common issues include DNS record errors or domain verification problems. The publish button remains disabled until all domain configuration errors are resolved. Make sure your DNS records are properly configured and the domain status shows as 'Active' before publishing.

Team workspaces with access control are planned but no timeframe is confirmed. The concept involves one builder instance with teams that have access to specific projects (Team A sees Site A, Team B sees Site B). For self-hosted deployments, this will likely be an enterprise feature, not open source. In the cloud, Webstudio plans to offer a team plan for this functionality.