How I managed to deploy my side project for free

After my latest post about lessons learned from doing side projects I’ve been asked to help some people with their side projects. One question that I’ve been asked a lot is — “How can I just play with code and publish my side project for free”. Many of us are building stupid side projects (Like this one) and we don’t want to spend money on hosting. I believe that you should publish your work to the world, so I came up with this guide for deploying a client-server web app to for free.

It’s all about the name

https://medium.com/media/0c65a3800bace6e2a0ae1a58e28776ec/href

Think about the following situation. You come back from a party and tell your roommate about his friend that you met there. You can say “He was tall, brown eyes, had a short beard…” It can take hours… Wouldn’t it be much faster to say “I met you friend Bob in the party”? The human brain is built for names. We give name to things, then we have alias to people, places and products. That’s why you want to have a domain instead of giving people your ip address (And you must admit, seeing links to ip addresses is suspicious anyway) . You can start with free domain from http://www.dot.tk/ and later on, when your side project starts to gain some traffic and maybe even bring in some money you can upgrade to a payed domain.

Static resources need static hosting

Hosting a static website should be pretty easy. You should be able to throw your files in the cloud, point a domain to that place, and let other people try your webapp. Netlify is a place to do exactly that! Their free plan is pretty good, letting you use your custom domain, SSL and configure your Git repo for auto deployment. It’s pretty straight forward and easy to use. You should checkout their Continuous deployment.

Server deployment

While static resources are easy to deploy (and cheap to host), server is a whole different story. When no one uses your app, your statice resources are doing nothing, but your server keep running. That’s why free server solutions are rare and limited. Lucky you — There are couple free server solution that I’m aware of.

Heroku gives you a free server. You can have your custom domain, but the server will go to sleep after 30 minutes of inactivity (and it takes time to wake up a sleeping server) and you are limited to certain number of computation hours.

now.sh gives you unlimited hours but you can’t have your custom domain — the meaning is that with every deployment you will have new url that points to the new version of your server, be aware that now.sh will also open source your code.

For my side project I decided to go with now.sh, but there are some things that I did to make my experience nicer.

How to hide sensitive parts of your code

OK, so I’m not really hiding part of my code. I didn’t try to do so, and I’m not sure you’re allowed to do it by now.sh license even if you find a way. I’m talking about my passwords.

I’m ok with open sourcing my code, but I don’t want my database connection string, my product email address and its password to be open to the world. The solution is environment variables. Passing those passwords while starting the app, instead of putting them hard coded is a good practice that you should always do, but when it comes to open source, it’s even more crucial. Now supports passing environment variables through it cli tool and you need to use that ability to keep your data safe.

How to overcome the ever changing server url

As I mentioned before, now.sh does not support custom urls in its free service. Every time you will deploy a new version of your server, your server url will be changed, so you need to change the client accordingly. The first step toward doing that is having one place in the client to set the server url. I tend to have a config.js file that exposes the server url.

const serverUrl = 'https://myserver.com';
const config = {
 SERVER\_URL: process.env.NODE\_ENV === "development" ? 
 "http://localhost:3000" : serverUrl 
};

export default config;

As you can see in the code above, this is a good practice for changing environments, but it’s also very good to have one place to declare the server url, so it’s easy to change it later.

Now I wrote a script to deploy. My script has three parts. It will deploy the server to now.sh, it will take the url that now will send back, then it will change the config.js file to point to the new server url and finally it will push the changes to my deploy branch so my client will be updated. I’ve open sourced this script as an npm package and you can see it here. (The readme file contains explanations of how exactly to use and configure this script).

I hope my post will help you to deploy your side project, and I would love to hear how you use my script or what is your side project in the comments or on Twitter. If you have any questions about the script or anything, don’t hesitate to ask me. My Twitter DM box is open. As always, you can follow me to hear about my next adventure in the programming world.