Static Site Hosting
With Kinsta’s Static Site Hosting, you can deploy static sites composed of non-dynamic files such as HTML, CSS, and JavaScript. Your repository can contain the pre-built files or the source code to generate your static site.
Kinsta has 260+ CDN locations for Static Site Hosting. Static sites are pushed to the edge at these CDN locations. This means visitors to your site are served from the closest, fastest, and easiest-to-access CDN location.
If you need further assistance with Static Site Hosting, don’t hesitate to join our Kinsta Community forum.
Git Service Providers
The first time you add a static site, you’ll need to select a Git service provider and repository from your account. You can choose from any (or all) of the following:
Once you’ve connected your Git provider account, you’ll be returned to MyKinsta to continue with the rest of the Add static site steps.
Features
You can add up to 100 static sites per company. Static sites use fewer resources because they do not require server-side processing or a database. They are also more secure because there are no scripting or database exploits to take advantage of. Check out our Static Site Hosting Features for a full list of what Kinsta’s Static Site Hosting has to offer.
Pricing
Static Site Hosting at Kinsta is free; however, it does include the following fair use policy limits:
- 100 sites overall
- 600 build minutes and 100 GB bandwidth per month per account
- 1 GB build size and 1 concurrent build per site
The Edge
The Edge is Cloudflare’s global network that places content geographically closer to the end users.
In typical cloud computing, data, and processing tasks are sent to centralized servers located in data centers. These servers handle data storage, processing, and delivery for various applications. However, sending data to distant data centers for processing may not be efficient due to factors like latency, bandwidth limitations, or the need for real-time processing.
That’s where the Edge comes in. It extends the capabilities of the cloud by placing computing resources and services closer to the end users or devices at the network’s edge. At Kinsta, we use Cloudflare’s content delivery network (CDN), with 260+ locations for Static Site Hosting.
Static sites are pushed to the edge at these CDN locations. Visitors to your site are served from the closest, fastest, and easiest-to-access CDN location so that data processing can occur much closer to the end users. This reduces the time it takes for data to travel back and forth to centralized cloud servers, which enables faster response times, lower latency, and improved performance for sites that require real-time or near-real-time processing.
This makes the Edge ideal for static sites as they consist of pre-rendered HTML, CSS, and JavaScript files that do not require server-side processing or database queries. They can also handle high-traffic loads more efficiently because they don’t rely on server-side processing. The Edge can serve the content independently, reducing the load on the origin server, improving overall performance, improving site reliability, and reducing points of failure.
Distributing content to the Edge also provides better resilience against network issues, reduces bandwidth requirements, and minimizes data transfer costs, optimizing cost efficiency.
Dynamic Content on Static Sites
Static sites do not have a backend server to execute server-side code or interact with databases dynamically; therefore, you can’t use dynamic content such as contact forms or a search function directly on a static site. However, you can use API calls from third-party services, such as Formspree, Getform, or Meilisearch, to incorporate dynamic functionalities into your static site.
Important Notes and Troubleshooting
If you’re having any trouble deploying your static site, check out our troubleshooting guide. Here are some important things to keep in mind:
- Kinsta’s Static Site Hosting is for pre-built static sites or sites built with modern static site generator frameworks that use Node.js. If your site meets any of the following conditions, it will be better suited for our Application Hosting:
- It uses a language other than Node.js to build the site (e.g. PHP).
- It requires server-rendering to serve some or all of the site.
- It requires a database connection.
- It serves dynamic content.
- It requires sessions or authentication managed on the server-side.
- You’ll be asked to specify a Build command and Publish directory during the setup process. The Build command tells our system how to assemble your site, and the Publish directory is the subdirectory where the finished site files live, relative to the root of your repository. It’s crucial to fill out these fields correctly if your site depends on a build step. This will ensure your site is built and served as you intend. If the Build command is left blank, the system may indicate the deployment is complete, but it will only upload the unbuilt contents of your repository.
- If you’re deploying a pre-built site and your files are in a subdirectory of your repository, be sure you’ve entered the path to that subdirectory (where your HTML files and assets are stored) in the Publish directory field, relative to the root of your repository.
- The Build and rollout process log for each deployment can be viewed on the Deployment details page.
- If a site is deleted, depending on the caching headers sent by the site and the user’s browsers settings, the deleted site may still appear to be available for a few minutes or hours due to caching.
- A static site’s Display name must be unique; it cannot be the same as another static site, application, or WordPress site.