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?
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 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
Once you know the file path of the directory to deploy, run the following command in a terminal window:
Your username (i.e. email address) will then display. Afterwards, you’ll just need to provide the file path for the project:
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.
Enter the domain name into your web browser and you should now see your site live:
Adding a custom domain name for your site
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
CNAME records will point to the following IP address:
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
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
* 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
To 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 firstname.lastname@example.org
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.
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
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
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.
*.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
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.
- LA County WIC Data
- Laycut Records
- Lolli Couture
- Madd Music Management
- Mark Petrie
- Musicians Booking
- Ocean Aid Hawaii
- Omega Water
- Permit Advisors
- Quick Uniforms
- Remote Web Guard
- Right Choice Developments
- Sakura Sushi Bar
- San Fran Ortho
- Sauk Valley Tennis
- Shark Tech
- Size Xchange
- An Introduction to Version Control using Git (2018 Update)
- Bash vs Zsh: A comparison of two command line shells (2018 Update)
- Did you just launch a new website? The ultimate guide on what to do next.
- Some common use cases of Sass
- WordPress Designer
- An introduction to the htaccess file:The Ultimate Guide (2018 Update)
- Build or Buy – Determining the Right Software Solutions for Your Business
- How to get rid of the “You have mail” Unix message
- Using node-sass to compile Sass files in an npm script
- Advanced Features of ECMAScript 6: The Ultimate Guide 2018
- Our custom design process
- Designing a simple navigation bar with Bootstrap 4
- Software Development Services
- Using A CSS Reset For Better Cross-Browser Compatibility
- Using WOW.js and Animate.css for Scroll-Triggered Animations
- WP Engine’s Staging Area has Revolutionized Our WordPress Development Process
- Responsive Web Design
- Medical Web Design
- Web Video Production
- Los Angeles Web Designer
- Tips For Keeping Your WordPress Site Secure
- Using chunkwm as a window manager
- Refactoring CSS Code (2018 Update)
- Using TextExpander To Increase Your Productivity
- Using ImageOptim for reducing image file sizes
- 4 Ways To Keep Your Data More Secure
- WordPress FAQ
- Joomla FAQ
- Choosing The Best Text Editor For Web Development
- Setting up an SSL Certificate
Crystal is a senior at a public high school in Santa Clarita, CA. She has been invested in technology since her sophomore year, when she took her first Web Development course and used Dreamweaver to design her first websites.
Crystal hopes to continue her studies in computing and technology in her post-secondary education.