Launch your own dev.to 🐳 server - with a single command (almost)!
Tags: showdev, docker, opensource, meta
Published: 2019-02-22 08:59:46

---
title: Launch your own dev.to 🐳 server - with a single command (almost)!
published: true
description: A single bash script command, for setting up dev.to for development, demos and maybe even production (in the future)
tags: #showdev #docker #opensource #meta
canonical_url: https://uilicious.com/blog/launch-your-own-dev-to-server-with-a-single-command-almost/
cover_image: https://thepracticaldev.s3.amazonaws.com/i/v9nqnej2oqns6hsozn3h.png
---

_(Disclaimer bash script has only been tested on Ubuntu / MacOS with docker)_

Clone the repository, execute the bash script, and follow its on screen instructions.

```bash
git clone https://github.com/uilicious/dev.to-docker.git && \
cd dev.to-docker && sudo ./docker-run.sh INTERACTIVE-DEMO
```

![Script command demo](https://thepracticaldev.s3.amazonaws.com/i/nhlrb6e52kctxt4fzrmv.gif)

---

# Longer docker based commands (no git clone)

Note: You will need replace all the various `<values>`

```bash
# Run a postgres server configured for dev.to
docker run -d --name dev-to-postgres \
	-e POSTGRES_PASSWORD=devto \
	-e POSTGRES_USER=devto \
	-e POSTGRES_DB=PracticalDeveloper_development \
	-v "<POSTGRES_DATA>:/var/lib/postgresql/data" \
	postgres:10.7-alpine;

# Wait about 30 seconds, to give the postgres container time to start
sleep 30

#
# Run the prebuilt dev.to container
# binded to localhost:3000
#
# Algoliasearch API key is required for dev.to,
# for login do consider adding github/twitter keys as well
# see : https://github.com/thepracticaldev/dev.to/blob/master/config/sample_application.yml
#
docker run -d -p 3000:3000 \
	--name dev-to-app \
	--link dev-to-postgres:db \
	-v "<DEVTO_UPLOAD_DIR>:/usr/src/app/public/uploads/" \
	-e ALGOLIASEARCH_APPLICATION_ID=<APP_ID> \
	-e ALGOLIASEARCH_SEARCH_ONLY_KEY=<SEARH_KEY> \
	-e ALGOLIASEARCH_API_KEY=<ADMIN_KEY> \
	uilicious/dev.to

#
# Also : do give 5~10 minutes for the server to be up. 
# It does take a long time to setup and start
#
```

Docker hub link : https://hub.docker.com/r/uilicious/dev.to

---
![Minion minion shouting joy scene](https://thepracticaldev.s3.amazonaws.com/i/7iwunbbyov3mftowthgc.gif)

![Dev.to on localhost:3000 example](https://thepracticaldev.s3.amazonaws.com/i/u4x9nfb5mlncywi37163.png)
<figcaption>Btw: I am very amused, by the various random article titles generated on a new deployment</figcaption>

{% github https://github.com/thepracticaldev/dev.to/pull/1844 %}

> PS: if someone can guide me on how to run dev.to in "Production" mode, it would be great in improving the overall docker container performance, in such a setup.

---

# Why do this? Isn't it possible to setup the server using the official readme ??

Well it started out with that, and ...

![I failed](https://thepracticaldev.s3.amazonaws.com/i/9e1hod91kjx34o1xyc5u.jpg)

Its not a problem specifically about dev.to, its simply me being **not** a ruby developer.

All I wanted was to simply spin up a quick server, so that I can try writing some UI test scripts on it (more on that later).

I really didn't want to be figuring out how to install ruby, sorting out missing os dependencies, and fix my npm versions, trying to figure out why the existing docker build have missing images, etc, etc.......

And in the middle of fixing all that, a flashback [on @ben's article from the past](https://dev.to/ben/how-devto-could-topple-facebook-2nj3) hit me ...

For this future where `dev.to` grows into a series of decentralised `dev.to.like` networks operated by the community to happen. We need the site to be something that is quick, and easy to deploy for _anyone_. 

Not just someone who "needs" to know how to ruby, postgres, nodejs, or even docker and docker compose for that matter...

We already have hundreds of other more _human_ hurdles in place to get a software adopted...

And in my subjective experience, the ability to get quick one liner demo up and running goes a long way in convincing others... Less is truly more here...

Convincing others in going beyond using `https://dev.to/` itself, but to use its open source codebase, perhaps adapt it to their own needs, or more importantly contribute to it!

For homebrew users, think of how many times have you used this one line for yourself or others

```bash
/usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"
```

It helps right? 

> The current script might not yet be there (for example we could auto install docker if its not present, and maybe in the future break the hard reliance on Algolia). But its one more step into that direction.

---

# So what were you saying about UI testing?

What I work on in uilicious, is to run test scripts like these

```js
// Lets go to dev.to
I.goTo("https://dev.to")

// Fill up search
I.fill("Search", "uilicious")
I.pressEnter()

// I should see myself or my co-founder
I.see("Shi Ling")
I.see("Eugene Cheah")
```

And churn out [sharable test result](https://snippet.uilicious.com/test/public/1cUHCW368zsHrByzHCkzLE) 

[![Uilicious Snippet dev.to test](https://thepracticaldev.s3.amazonaws.com/i/gyrtj5lk2b2bn89z7ra1.gif)](https://snippet.uilicious.com/test/public/1cUHCW368zsHrByzHCkzLE)

Like the above.

However there is one huge problem with it, that I am trying to solve for UI testing in general (not just for Uilicious)... 

Which is getting everyone ... _To run UI tests as soon as its committed - just like how we run unit tests._ (be it uilicious as a development company, its customers, or any dev in general)

Because unfortunately, from what I see - majority of our users on our platform, is testing only on production. With slightly less then half having a testing/staging server. And finally, a very very small fraction testing on a git push.

![Please do not test in production](https://thepracticaldev.s3.amazonaws.com/i/vdxtfl6d06nwxoekp2ck.jpg)

In development, the earlier a test fails and notifies a developer, the better it is for everyone.

And typically the biggest hurdle in reaching there, is not just getting automated UI tests, but ...

> [Can you make a build in one step? : If the process takes any more than one step, it is prone to errors](https://www.joelonsoftware.com/2000/08/09/the-joel-test-12-steps-to-better-code/) 
> ~ over simplifying Joel Spolsky 

**Or more specifically, can you build, deploy, and test in one step?**

Hence it is my small hope, that by making dev.to easier to build and run. 

All I need to do next (@TODO in next article), is to chain it together with travis for temporary deployments. And finally a process where I can run UI test scripts with git pushes. 

Allowing it to serve as an example use case for other dev in doing full UI testing on specific git pushes....

And maybe, maybe perhaps, convince the [dev.to team to sign up for our product. or free trial](https://uilicious.com/pricing.html) 😉

---

# Oh, one more thing - DEV mode

```bash
./docker-run.sh DEV
```

![dev.to dev mode](https://thepracticaldev.s3.amazonaws.com/i/c4b4tsy3qgtht0y2peda.gif)

A single bash script, to help - not just with testing and demos, but hopefully dev too.

A single line command, to setup your entire dev environment from a cloned repository, and straight into bash. 

No ruby/npm installation needed. 

---

> PS : If anyone have feedback how I can make this build and deploy script better / etc. Do let me know

# Happy shipping 🖖🏼🚀