Frequently Asked Questions
On this page
Do you have a question that is not answered here? Email hello@statichost.eu!
What is the difference between statichost.eu and other providers such as GitHub Pages or Cloudflare Pages?
statichost.eu is a European provider and we don’t store any personal data from visitors. Also, you get more flexibility regarding how your site is built on our platform.
-
We don’t store or process any personal data - ever. Not in server logs and not in analytics tools (Cloudflare by default adds their own analytics script on your site). Plus, as a European provider, we are protected by very strong privacy and freedom of speech laws.
-
With statichost.eu, you can build your site with any Docker image, while on Cloudflare Pages you have to use their environment. In GitHub, you need to set up a CI workflow if you’re not using Jekyll.
-
With us, you can use any git provider you choose. On GitHub you’re obviously on GitHub, while on Cloudflare you can also use GitLab.
How do I switch to statichost.eu from my current provider?
Switching to statichost.eu requires deploying your website on statichost.eu and then changing your DNS records to point to our servers. Switching does not create any downtime for your website.
Here are the concrete steps:
- Add and build your site on statichost.eu.
- Check that your site works as expected on your-site.statichost.eu. *
- Configure your domain(s) for statichost.eu. **
When the first request for your custom domain (e.g. your-site.com) comes to our servers, we will automatically provision a new SSL certificate for your domain. Thus, this first request will take a second or two to complete, but there will be no actual downtime. And subsequent requests will of course be lightning fast!
*) If you use absolute URLs (e.g. https://your-site.com/styles.css) for some resources, these resources might not work because of CORS- or other issues. While your site will work as expected after the DNS update, you might want to fix these issues by using relative URLs (e.g. /style.css) beforehand.
**) Remember to build your site before updating your DNS records.
How do you ensure that all websites are always online and available?
We employ industry best practices and have extensive monitoring in place with immediate escalation in case of problems. Having said that, with no site-based redundancy, our uptime at the time of writing is 100.000% for the past 90 days. Check our status page for an up-to-date figure and more information.
Customers who require very high levels of redundancy may use our CDN solution for Europe- or world-wide replication (provided by acache.io). Contact support for more information.
Here are some of the things we do to keep your site online:
- Servers are as robust and as simple as they can be - they are designed to do one thing, and that is to serve static files.
- Contiuous HTTP monitoring by Better Uptime with immediate incident escalation.
- Server health monitoring using our own ElasticSearch cluster.
- Rapid infrastructure deployment using Terraform.
Note: One of the best things with static sites is that the production setup is extremely robust and simple. All you need is a standard web server and the static files.
What git providers are supported?
You can use any git provider you want. We use standard git under the hood, which
means any repository URL that the git command understands works. If your can do
git clone https://mygit.org/repository.git
, you can use it on statichost.eu.
Note: The URL needs to be reachable from our build server, of course. Contact support for special setups, such as internal-only git servers.
How does billing work, and what happens if my site exceedes the free quota?
Nothing will happen if you exceed the free quota. We don’t employ hard limits and will continue to serve your site regardless. We will contact customers who exceed the quota separately in order to set up payment. But don’t worry, we will give you ample time to get everything sorted out!
What information is stored in server logs, and for how long?
We don’t store any personal information in logs. We only store the bare minimum information required for billing purposes (mainly response size). Here is a real excerpt from our log file:
{
"level": "info",
"ts": 1688112443.6190288,
"logger": "http.log.access.log0",
"msg": "handled request",
"request": {
"proto": "HTTP/2.0",
"method": "GET",
"host": "www.statichost.eu"
},
"duration": 0.001340271,
"size": 3291,
"status": 200
}
We process our logs for billing periodically, which in practice means we aggregate the response size by site. After this the processed log files are deleted. Logs are kept for a maximum of 7 days - however, usually they are deleted sooner than that.
Log files are stored on our edge servers and transferred to our builder platform for processing, after which they are deleted.