Goodbye CMS: we remade host.it with Astro, and marketing now runs on its own

WordPress, Joomla and other CMS have made the Web accessible to millions of people and continue to be suitable tools for many projects. But our institutional site had different needs: most pages change when marketing decides, not with every HTTP request.

• 90% of the site was not dynamic. Product pages, price lists and institutional content did not need to be regenerated by the server at each visit.
• The attack surface was not proportionate. PHP runtime, database, administrative panel and plugins require continuous updates and checks, even when the site only needs to display content.
• The bottleneck was organisational. To edit a page, skills were needed across copywriting, graphics, development and release.

Astro is a modern framework designed for content-oriented sites. During build, transform components, data and pages into ready-to-deploy HTML files. When a visitor opens host.it, the server does not have to query a database or run PHP to compose the response.

Zero JavaScript by default

Astro sends HTML and CSS to the browser. JavaScript is only added to components that need to be truly interactive: the visitor does not download a complete application to read a page.

Island architecture

A form, a configurator or a widget can become an interactive island, loaded when needed. The rest of the page remains static HTML. This reduces the code that runs in the browser and makes it easier to control performance and behavior.

Components and contents validated during the build phase

Pages and components are checked before publishing. If a necessary data is missing, a link does not respect the schema or the project does not compile, the pipeline stops: the error is not discovered by the customer in production.

The result: CDN-ready static files

The final output is a folder of HTML, CSS, JavaScript and image files. There is no application process to start and a user session is not needed to show a page. Response time depends primarily on the network and location of the CDN node, not on how well an application works on each visit.

Saying that a site is "non-vulnerable" would be technically incorrect: repositories, CI/CD pipelines, accounts, dependencies, DNS and CDN remain components to be protected. The concrete advantage is another: on the public site entire classes of application vulnerabilities typical of a dynamic stack disappear.

• No PHP running. There is no public runtime through which to run server-side code or load a webshell.
• No database to compose the pages. There are no queries exposed to navigation and therefore there is no SQL injection on the static content.
• No public administrative panel. There is no CMS login page to brute force or credential stuffing.
• No plugin chain in the public perimeter. The visitor does not interact with server-side extensions to be maintained and updated continuously.
• Content published in a controlled manner. To modify the site you must go through the build and deploy pipeline, which is protected and tracked.

The new site is distributed by our CDN: the pages are replicated and served by edge nodes close to the users. This reduces latency and load on the source infrastructure.

However, there is a benefit that goes beyond speed. With the “always online” functionality, the CDN can continue to serve the static copy of the site even if the origin server is temporarily unreachable. A maintenance or source failure should not automatically result in an offline site.

In this architecture the origin is essential to publish a new version, but not to generate every requested page. Content already distributed remains available on the CDN network.

The most important change is not only in the infrastructure. Previously, to publish a new product page, separate copywriting, graphics, frontend development, revision and deployment interventions were needed. Today the marketing team can manage the entire cycle with an AI-assisted pipeline.

• Contents. Writing and revision of texts with structure, SEO, tone of voice and translations managed in the same flow.
• Graphics. Covers and visual assets produced in the formats required by the design system.
• Layout. The pages are composed with already approved components: the AI ​​uses the design system, it does not bypass it.
• Automated testing. Builds, validations and functional checks are performed before publication.
• Separate staging and production. Each change is first generated and verified in staging, then promoted to production.

Switching to a static site isn't free and it's not the universal answer. To obtain a reliable result you need a solid design system, a CI/CD pipeline with separate environments, automatic tests and a precise strategy for the truly dynamic parts.

• Forms and integrations. They must be entrusted to dedicated endpoints or services, with the same attention to security as any application.
• Search and interactive tools. They can live like islands, without turning the entire site into a JavaScript application.
• Restricted areas and real-time data. Require a separate backend or application service.

For applications with personalized content per user, e-commerce with real-time prices and availability or portals with extensive reserved areas, a CMS or a dynamic application may remain the right choice. In fact, we continue to host and protect thousands of them: the point is not to eliminate the dynamic, but to use it only where it creates value.

The new host.it is faster, but above all it is more difficult to compromise, more resilient and easier to update. Performance, security, and marketing autonomy come from the same choice: build once, test, and deploy everywhere.

If you build sites for clients and want to understand if this model makes sense for your portfolio, let's talk. To organize controlled releases you can learn more about our staging and development service.