Using Surge for deploying static sites (2019 Update)

Using Surge for deploying static sites

Static Site Generators have become increasingly popular over the past several years. They’re great for any projects not requiring server-side processing. There’s been an emergence of services such as webtask.io and others for handling server endpoints. This has no doubt contributed to the growth of static sites and “serverless” web applications. Many see this as a major new direction for web app development because of their efficiency and typically lack of financial cost. One such tool for dealing with static sites is Surge.

Of the many draws for using static site generators, the relative ease of building and deploying is significant. These types of deployments simplify the oft-involved and tedious process of setting up and managing a production server. This blog post will give an introduction to using Surge, a real static site deploying gem. It is an easy-to-use tool for publishing a production-ready static site live in a matter of minutes.

What is a static website and static site generator?

Before diving into Surge, you should understand what we mean when we refer to “static websites.” Static sites are created with HTML files. Therefore, each webpage on the site has its own HTML file with fixed website content that displays the same for any user on any platform. These files require relatively no programming knowledge and are the most basic type of website to create, as opposed to dynamic websites. Static sites are manageable for smaller websites; however as your website requires more webpages, it is recommended to build a dynamic website so the code does not need to be manually updated.

By using a static site generator, you are feeding the SSG the source files you’ve created, which it then assembles into a static website. When a client requests your website, the HTML files are neatly packaged into a site that can be immediately displayed on their device. Some popular static site generators include Jekyll, which is supported by Github Pages, and Next.

What is Surge?

Surge is a service for deploying and hosting static websites and applications. You can use it to host projects built with static-site generators such as Gatsby.js, Jekyll. Any custom project built with HTML, CSS and client-side JavaScript will work as well. Its free plan is optimal for just about any static site, and configuring the service can be done with just a few keystrokes into your command line. There is a premium version available that adds some additional features such as Custom SSL, password protection and more.

Why should I use Surge?

Surge is a highly convenient tool that any front-end web developer should familiarize themselves with. It is extremely straightforward to use and you can publish a static site onto the Internet literally within seconds. All web publishing requires is a few commands into the command line. The best part is, there is no investment required. Surge users can also add personal domains to their projects, share your project with other users, and even create a custom 404 error page to direct clients to other parts of your website in times of need. Surge even has some unique benefits that other popular static site deployers lack (see “Comparison of Surge and Github Pages”).

Is Surge a free service?

As implied above, Surge does not require any cost to use.
However, there is a Surge Professional that comes with more benefits for users who are willing to invest the extra fees. This premium version of the service comes at $30 per month. Specifically with the additional fee, you can create unlimited professional projects, have a custom SSL, and have a secured website with https. In addition, you can share resources, create redirects within your website, and protect your projects with passwords.

If you are simply planning to publish source files to create a small-scale or personal website, then the free plan should suffice. However, for anyone who regularly depends on Surge for publishing projects, then Surge Premium can also be considered a wise option.

Installing Surge

Installing Surge and setting up an account is extremely simple and intuitive. Simply open up a new terminal window and type the following command:

npm install --global surge 

(Note: this step assumes Node and npm are already installed on your system. If not, you can install the latest version of both from the official Node.js website.)

Upon your first time setting up, Surge will ask you to set up an account. The only requirements are is providing an email address and password, and verifying your email afterwards. Upon completing this step, you’ll now be setup with a Surge account and ready to deploy to their service.

Deploying your site

To deploy your static site to Surge, first find the file path of the project directory you want to deploy. As an example, I’m going to deploy a project located at /Users/air/surge-test.

Once you know the file path of the directory to deploy, run the following command in a terminal window:

surge

 

Your username (i.e. email address) will then display. Afterwards, you’ll just need to provide the file path for the project:

deploy your static site to Surge

Enter the full file path, then hit enter.

Surge will automatically provide a domain name using random words. You can also create any custom domain if it is not already taken. Enter your chosen domain name, then hit enter.

(Note: If the custom domain name you input is already taken, you’ll see an error message.

Aborted - you do not have permission to publish to [<custom-domain.surge.sh>]

 

Once deployment is complete, you’ll see a success message displayed in your terminal. The domain name and IP address for the project will show you where you can access the live deployment.

surge deployment

Enter the domain name into your web browser and you should now see your site live:

deploying static sites with surge

Adding a custom domain name for your site

Using a CNAME record

By default, Surge will provide a custom subdomain for any site that you deploy to their service. It will look something like your-custom-domain.surge.sh. You can customize and select what the subdomain is (provided it’s not already taken). Chances are, though, that you’ll want to use your own custom domain for any professional project.

To do so, you’ll want to add two new CNAME records in the DNS panel of your domain provider. One will be with a hostname of @, and the other will be with a hostname of www. Both CNAME records will point to the following IP address:

na-west1.surge.sh

Using an A record

If for some reason your domain provider doesn’t allow CNAME records, you can set an A record as an alternative. Have the A record point to an IP address of 45.55.110.124.

Using custom subdomains

You can also use any custom subdomain to point to Surge, such as sub.my-cool-site.com. To do so, you’ll want to set up a new CNAME record. This should point to the same na-west1.surge.sh IP address above, but this time the hostname will be *. The * hostname is a wildcard. This means that any subdomain apart of the primary domain will be valid and allowed.

Surge will recognize these DNS changes immediately. It can take take time to propagate elsewhere, however, typically no more than 24 – 48 hours.

Deploying your project using a custom domain

Once the DNS settings have taken effect, you can now deploy your project. You’ll just need to indicate the domain that you’d like to use. To do so, run the surge command in your terminal. Indicate the file path to your project first, then the custom domain afterwards, like so:

surge filepath/of/project a-cool-custom-domain.com

 

Bind your custom domain to the project

You may want to bind your domain to the project so you don’t have to enter it whenever you deploy. You can do so using the echo command, directing it to a CNAME file, like so:

echo a-cool-custom-domain.com > CNAME

 

Sharing your Surge project

Sunlight Media LLC: Sharing your Surge projectTo give other Surge users publishing permission, you must first publish your project. Then, type in the add command into the command line to begin adding collaborators by their email address.

surge --add collaborator@email.com

Anyone that you have added to your project and has accepted your invitation now has the ability to publish their source files into the same domain.

 

Listing Surge projects

To view all of the projects that you have published using Surge, type this simple Surge command into your command line. This will generate a list of all of your projects.

surge list

 

Adding custom 404 error page

If you would prefer to replace the default 404 error page with one custom-built, all you have to do is add a 404.html file to your Surge project. When you are ready to deploy the new 404 file, just command surge.

 

Create a .surgeignore file,/h2>

Much like the .gitignore file in the Git ecosystem, Surge offers its own ignore file. You can set up a list of files and directories that Surge will ignore at the time of deployment. This is useful for leaving out files that may only be relevant during the development process. Anything that you might want to keep entirely private is good to include here as well.

To set this up, create a new file called .surgeignore in the root of your project folder. Inside of this file, you can list any files and directories you’d like to to ignore. Some common examples might include node_modules, bower_components, and others. You can also ignore specific file types that aren’t relevant to the production version of a site. Adding * (the wildcard symbol) before the extension (i.e. *.swp, *.psd, etc.) will accomplish this.

Take down your site from Surge

If for some reason you’d like to take down your site, you can do this easily with the surge teardown command, followed by your project’s domain.

surge teardown your-domain.com

Before attempting to remove your project, ensure that your version of Surge is updated to the latest version.

 

Comparison of Surge and Github Pages

Similar to Surge, another popular alternative static hosting service is Github Pages. This free service allows users to host their personal static site projects into a Github repository. Github Pages boasts an extremely well-known reputation among web developers of any caliber as one of the highest-ranked static hosting services. There are two types of pages that can be built—Project pages or User and Organization pages—which can be created under the domain github.io. Of course, you have the freedom of using a custom domain as well. Github explicitly recommends that any projects that are intended to accomplish commercial purposes should not be published using their hosting service. Therefore, while it may be unable to accommodate large-scale websites, Github Pages is perfect for non-commercial or personal uses.

There are slight variations between the Project pages and User and Organization pages. Project pages can be published from multiple source locations including the master and gh-pages branches. Without a custom domain, the default publishing domain would be https://<username/orgname>.github.io/. On the other hand, User and Organization pages are located in the master branch under your Github repository. They are published with the domain https://<username/orgname>.github.io.

Benefits of Surge

While Github Pages is undoubtedly a powerful tool, Surge offers some benefits that even Github Pages lacks. One of these benefits is client side routing. Within your Surge project, you can redirect clients to a “backup” HTML file (200.html) if they request a nonexistent path. This is beneficial because rather than displaying an alarming 404 error, Surge will simply serve the fallback file.

Another notable benefit to Surge is that users can deploy any new changes to their site in a matter of seconds. As stated above, by simply typing the surge command into the command line, any changes you have made can be instantly viewed online. This efficiency can be especially helpful when you are simply experimenting with minor tweaks in your site because you can immediately refresh to see the changes in your web browser. On the other hand, for Github Pages users, anyone knows that pushing and committing changes to your repository is a relatively longer and more tedious process that can be confusing for first-time developers.

Resources

Post a Comment

Comments are moderated. Your email is kept private. Required fields are marked *

© 2019 Sunlight Media LLC