Astro is an option for institutional sites, blogs, documentation and product pages. It also combines well with a stream where AI helps write components and content. But finishing the interface on the computer does not complete the publication: you need to turn the project into production files, put them in the correct directory and test the real address. This guide presents a verifiable static path on the WordPane panel and explains what changes when processing on the server exists.
Before you start: Identify project output
Open the repository and check the package.json, the Astro configuration file and the used integrations. The simplest case is a fully pre-rendered site. In this scenario, build produces files that a web server can deliver without keeping the Astro development process running. Official deploy documentation indicates dist as the default output directory.
If the project uses dynamic endpoints, sessions or on-demand rendering, it may require an adapter and runtime. Do not try to publish only the interface and wait for authentication or API to appear automatically. Also note external services, variables, domain, forms, and the destination of the submitted data. This list defines the environment and validation tasks.
Generate and check the production version
Execute the following commands in the project folder. The example presupposes npm and package-lock.json version; if you use another manager, keep the project manager and lockfile. Check the Node version required by your Astro version. Stop if the installation or build fails and correct the error before sending files.
Use the local preview to check the pages and build result. The preview serves as a conference, not as a permanent production service. Open an internal page directly, examine the images and test the form. Check if the public URL and canonical point to your domain instead of the localhost address.
npm ci
npm run build
npm run previewPrepare the application in the panel
In the client area, choose compatible infrastructure and wait for completion of server configuration. For a static site, evaluate a web environment that allows you to serve project files. You don't need to hire a runtime Node just because Astro uses Node during build. Generation can happen on your computer or in an IC automation.
The path observed in the panel is Applications → Create an Application → Custom. The PHP version fields of this form belong to the custom PHP application; they do not transform the Astro into PHP. The relevant use for the static site is to prepare domain, user and public directory that will serve the files. Check this behavior in the chosen stack.
- Inform Application Name and select Primary Domain or Test Domain.
- For your own domain, please enter the address and review the SSL option; DNS needs to point to the correct destination.
- Choose Custom and review System User in Show Advance Options.
- Check Custom Webroot. Destination must match the folder that will receive the generated content, not the source directory.
- Create the application and check the path in File Manager before sending the build.
Send dist content to webroot
In the application file manager, confirm the breadcrumb and the path. The webroot observed in our documentation is public_html; a project with Custom Webroot can use another destination. Send the internal dist content to that folder, preserving subfolders and names. If you put the entire dist folder inside public_html, index.html can be a level below what the server is looking for.
Use File Manager or SFTP with the correct user. Keep a copy of the previous site before replacing files. Do not send .env, .git, credentials files or development environment dependencies to the public folder. For future updates, publish the full build consistently: New HTML with old assets, or otherwise, you can break the page.
Integrate Git without skipping the build step
Git integration allows you to link account, repository, and branch to the application that makes this feature available. It does not in itself mean that every project will have installed and built-up dependencies. In WordPane documentation, the application created by the Git method offers its own update options; there is no universal build field confirmed for all stacks.
You can generate the files in an external routine and publish the artifacts, or perform a build procedure in the environment that has runtime, permissions and resources required. Document which method your team has adopted. Only enable automatic update after proving that a commit produces the final files in the webroot and that there is a way to recover the previous version.
What changes with Astro and SSR
For server rendering, please refer to the official Node adapter and documentation corresponding to the project version. This architecture needs a production process, run configuration and proxy. WordPane's Node.js environment is in beta; check version, command, port, variables and controls available before hiring.
Do not copy the PHP form as if it were the Node form. If the application depends on a runtime edge or a specific service from another provider, prepare the adaptation. Hosting the code in VPS does not automatically play Vercel or Cloudflare services. In this case, send the requirements and production command to the team before you follow.
Validate domain and resolve the most common flaws
- Home works, but a route returns 404: check out build output, URL rules, and folder structure.
- CSS or images fail: check the base path and if the generated assets have been published with HTML.
- Form does not send: check the actual endpoint and the responsible backend; static HTML does not process messages alone.
- A change does not appear: confirm branch, build, destination directory and browser cache.
- SSL does not conclude: check the DNS and domain configuration before repeating the issue.
- Before disclosing, test menu, internal pages, social metadata and the registration your project offers.
Where WordPane Adds to Routine
The platform brings together the creation or connection of the server, tracking operations and consumption in the client area. In the control panel, you find tools for domain, files, Git integration, logs and backup according to the configured environment. This organizes tasks that would continue to exist even when the AI produces much of the code.
Hourly charging allows you to track the consumption of the environment in the balance. The cost of the infrastructure is separated from models of AI, APIs and external services used by the project. Start with a test publication, record the steps that have worked and choose the resources based on the observed behavior. The first useful result is an accessible, up-to-date and recoverable website.
Choose the project environment
Compare the plans or send the application requirements to the WordPane team.
Configure my project in WordPaneConsult panel documentation
