Moss blog

Two years ago we launched Moss commercially. That was our first attempt to help web developers manage their servers and sites so that they could focus on their business and build great applications. Since then, we’ve been learning from our customers and evolving Moss in accordance.

Thanks to this continuous learning process and the effort of our team, now I’m proud to announce our new version of Moss. A major update that puts the focus on the unique features that set Moss apart: real-time visibility, security, and integration with 3rd-parties.

Website owners want their sites to run as fast as possible – and the well-known W3 Total Cache plugin (W3TC) is a popular option to optimize your WordPress installations. When W3TC is properly configured, it will help your server handle greater traffic loads without jeopardizing the response time of your website.

W3TC offers lots of functionality for free, while some premium features are unlocked when the user upgrades to their Pro plan. However, the plugin lacks some documentation and it’s not always easy to understand which features must be enabled and set up.

In the remainder of this article I’ll review the main caches you can set up with W3TC in order to optimize WordPress. You’ll see how they work and the main settings you can fine-tune. I’ll also point out at some alternative solutions you might explore in some – more advanced – use cases. Let’s start!

The PHP development team released PHP 7.3.0 five days ago. Today we’re happy to announce that Moss fully supports the brand new 7.3 branch of your favorite language!

Upgrading your website to PHP 7.3 with Moss is quite a simple thing: Just choose the new version in the settings of your site(s). However, there are some things to consider before jumping into 7.3. Like with every release, some features come in and others go out. Let’s see how to safely upgrade your application without unpleasant surprises.

When you host multiple websites on a same server, your server needs a way to know the website it must return when an HTTP request arrives. The most widespread solution is to rely on the Host: header the client (usually the web browser) includes in the request. When HTTPS is involved, the SNI extension (Server Name Indication) is used to determine the certificate that must be used to secure the connection. The web server will employ the given hostname to serve the appropriate website.

The former implies that the hostname must resolve to the IP address of your server. But what if you’re creating the website on your local development machine? What if you’re just testing a tool like Moss to see if it fits your needs? Most likely you don’t want to create new DNS records yet, so there must be a more convenient solution.

Meet wildcard DNS services for IP addresses. A domain name like www.10.0.0.1.xip.moss.sh www.10.0.0.1.getmoss.siteresolves to IP address 10.0.0.1. You don’t have to set up anything, just choose the appropriate domain name based on the IP address of your server. We encourage our users to use a wildcard DNS service while they’re trialing Moss, because it’s the fastest way to get started.

In the remainder of this article I’ll briefly review and compare the most relevant free wildcard DNS services you can use when you don’t want to mess with the DNS records of your own domain yet.

Last week we supported GitLab as a first-class citizen in Moss. If you host your application code in GitLab.com repositories, you can now enjoy all Moss features that previously were only available for GitHub and Bitbucket. As in the latter cases, you just have to authorize Moss to access your GitLab account and it’ll be able to deploy your GitLab-hosted repos.

In this way you can trigger automatic deployments after pushing your code, or deploy manually with just one click. In either case, your websites will benefit from a zero-downtime process. Want to know the details? Please keep reading 😀