Application and Data / Application Hosting / Web Servers
Avatar of zimoony
Senior Fullstack Developer at QUANTUSflow Software GmbH·

Our whole DevOps stack consists of the following tools:

  • GitHub (incl. GitHub Pages/Markdown for Documentation, GettingStarted and HowTo's) for collaborative review and code management tool
  • Respectively Git as revision control system
  • SourceTree as Git GUI
  • Visual Studio Code as IDE
  • CircleCI for continuous integration (automatize development process)
  • Prettier / TSLint / ESLint as code linter
  • SonarQube as quality gate
  • Docker as container management (incl. Docker Compose for multi-container application management)
  • VirtualBox for operating system simulation tests
  • Kubernetes as cluster management for docker containers
  • Heroku for deploying in test environments
  • nginx as web server (preferably used as facade server in production environment)
  • SSLMate (using OpenSSL) for certificate management
  • Amazon EC2 (incl. Amazon S3) for deploying in stage (production-like) and production environments
  • PostgreSQL as preferred database system
  • Redis as preferred in-memory database/store (great for caching)

The main reason we have chosen Kubernetes over Docker Swarm is related to the following artifacts:

  • Key features: Easy and flexible installation, Clear dashboard, Great scaling operations, Monitoring is an integral part, Great load balancing concepts, Monitors the condition and ensures compensation in the event of failure.
  • Applications: An application can be deployed using a combination of pods, deployments, and services (or micro-services).
  • Functionality: Kubernetes as a complex installation and setup process, but it not as limited as Docker Swarm.
  • Monitoring: It supports multiple versions of logging and monitoring when the services are deployed within the cluster (Elasticsearch/Kibana (ELK), Heapster/Grafana, Sysdig cloud integration).
  • Scalability: All-in-one framework for distributed systems.
  • Other Benefits: Kubernetes is backed by the Cloud Native Computing Foundation (CNCF), huge community among container orchestration tools, it is an open source and modular tool that works with any OS.
25 upvotes·2 comments·672.1K views
Avatar of CmdrKeen
Co-founder & CEO at Raygun·

We chose AWS because, at the time, it was really the only cloud provider to choose from.

We tend to use their basic building blocks (EC2, ELB, Amazon S3, Amazon RDS) rather than vendor specific components like databases and queuing. We deliberately decided to do this to ensure we could provide multi-cloud support or potentially move to another cloud provider if the offering was better for our customers.

We’ve utilized c3.large nodes for both the Node.js deployment and then for the .NET Core deployment. Both sit as backends behind an nginx instance and are managed using scaling groups in Amazon EC2 sitting behind a standard AWS Elastic Load Balancing (ELB).

While we’re satisfied with AWS, we do review our decision each year and have looked at Azure and Google Cloud offerings.

#CloudHosting #WebServers #CloudStorage #LoadBalancerReverseProxy

How Raygun Processes Millions of Error Events Per Second - Raygun Tech Stack | StackShare (
19 upvotes·240.7K views

Recently I have been working on an open source stack to help people consolidate their personal health data in a single database so that AI and analytics apps can be run against it to find personalized treatments. We chose to go with a #containerized approach leveraging Docker #containers with a local development environment setup with Docker Compose and nginx for container routing. For the production environment we chose to pull code from GitHub and build/push images using Jenkins and using Kubernetes to deploy to Amazon EC2.

We also implemented a dashboard app to handle user authentication/authorization, as well as a custom SSO server that runs on Heroku which allows experts to easily visit more than one instance without having to login repeatedly. The #Backend was implemented using my favorite #Stack which consists of FeathersJS on top of Node.js and ExpressJS with PostgreSQL as the main database. The #Frontend was implemented using React, Redux.js, Semantic UI React and the FeathersJS client. Though testing was light on this project, we chose to use AVA as well as ESLint to keep the codebase clean and consistent.

15 upvotes·1.5M views
Avatar of Epistol·

I use Laravel because it's the most advances PHP framework out there, easy to maintain, easy to upgrade and most of all : easy to get a handle on, and to follow every new technology ! PhpStorm is our main software to code, as of simplicity and full range of tools for a modern application.

Google Analytics Analytics of course for a tailored analytics, Bulma as an innovative CSS framework, coupled with our Sass (Scss) pre-processor.

As of more basic stuff, we use HTML5, JavaScript (but with Vue.js too) and Webpack to handle the generation of all this.

To deploy, we set up Buddy to easily send the updates on our nginx / Ubuntu server, where it will connect to our GitHub Git private repository, pull and do all the operations needed with Deployer .

CloudFlare ensure the rapidity of distribution of our content, and Let's Encrypt the https certificate that is more than necessary when we'll want to sell some products with our Stripe api calls.

Asana is here to let us list all the functionalities, possibilities and ideas we want to implement.

12 upvotes·2 comments·699.3K views
Avatar of gp187
CEO at NaoLogic Inc·

We switched to Traefik so we can use the REST API to dynamically configure subdomains and have the ability to redirect between multiple servers.

We still use nginx with a docker-compose to expose the traffic from our APIs and TCP microservices, but for managing routing to the internet Traefik does a much better job

Naologic (
11 upvotes·2 comments·328K views

I just designed, developed, and deployed my own budgeting app,, which allows me to automate my budgeting the way I have always done it, in a way that I could never fully capture with other budgeting apps, such as Mint, EveryDollar, or YNAB. I spent 4 years from the time I first had the idea to the time I actually sat down to design it and start development. During this time I evaluated many other budgeting app solutions, and had even architected a prototype that I never ended up using. But boy, have technologies come much further in 4 years.

Though my first prototype used Java and Tomcat, I completely abandoned those 4 years later in favor of Node.js technologies, which I have found are equally as stable, more flexible (for better or for worse), and capable of significantly more rapid development. Since what I have deployed now is in beta and is primarily for limited user use, I favored rapid development over slower development where I would write more automated unit tests. I chose to build the app as a HTML5 web application (rather than native iOS or Android, for now), and I used a separated API backend/Web frontend model. My target platform for use with the app is mobile handheld touch devices, though it can work on any laptop or desktop with a touchscreen. Given these design targets, many of the technologies I chose were because of familiarity with them as well as a strong online community, and some technologies I chose that I had to learn anew, because they appeared to fit my needs.

My entire app runs on a #lenovo IdeaCentre desktop on my home network, on which I have installed Ubuntu 18.04. Ubuntu is something I have switched to after a long time of use and familiarity with RedHat Enterprise Linux and CentOS, because the online support for Ubuntu is now tremendous, and there is so much documentation and examples online of how to configure and use Ubuntu; not to mention I have not been thrilled with the direction new releases of CentOS. Ubuntu is also a good environment for development - it is so easy to follow the many online examples. Lastly, I may migrate my app and configuration to Amazon AWS, which also uses Ubuntu for its EC2 Linux VMs, so having Ubuntu now is helpful for that prospect.

The API backend uses Node.js, with #HapiJS as the API server framework and MySQL as my persistence database. HapiJS is something I have had familiarity with and is just a phenomenal framework to plug into and configure, especially if you use it for a route-based API. #Mysql has a great online community. I could've used PostgreSQL too, but I am more familiar with MySQL. Also, if I migrate to Amazon AWS, Amazon's RDS uses MySQL. I use npm as a one-stop-shop package manager and environment manager.

The Web frontend uses a combination of Framework7 and Vue.js. I cannot evangelize Framework7 enough! It is a fantasic tool by @nolimits4web (GitHub) that is really easy to use, really well thought out, and really performant. Framework7 simulates the native iOS or Android (Google Material) experiences, all using HTML5 constructs (HTML+CSS+JS). Vue.js is another very fantastic binding and frontend framework which has a good online community and is well documented and easy to use. I had to choose between VueJS and ReactJS, and ultimately chose VueJS over ReactJS because it seemed to favor more rapid development with less ramp-up time, whereas I understood ReactJS to be more of an enterprise level framework (though still good for smaller projects like mine). When using Framework7 with VueJS, NodeJS is used along with Webpack to transpile my code into browser-friendly JavaScript, HTML, etc. Webpack was nice to use because it has a hot-deploy development mode to enable rapid development without me having stop, recompile, and start my server (this was one of several reasons against using Java with Tomcat). I had no familiarity with Framework7, VueJS, or Webpack prior to this project.

I use nginx as my web server and have the API running behind a reverse proxy, and all of the web frontent content hosted as static content.

I use the plaid API to sync my bank transactions to my database. This is another fantastic framework (though not free beyond development use) that it turns out is extremely easy to use for the complex job that it solves.

10 upvotes·2 comments·390.5K views
Avatar of cwray-tech
Owner, Developer at Soltech LLC·

This week, we finally released In the end, I chose to provision our server on DigitalOcean. So far, I am SO happy with that decision. Although setting everything up was a challenge, and I learned a lot, DigitalOceans blogs helped in so many ways. I was able to set up nginx and the Laravel web app pretty smoothly. I am also using Buddy for deploying changes made in git, which is super awesome. All I have to do in order to deploy is push my code to my private repo, and buddy transfers everything over to DigitalOcean. So far, we haven't had any downtime and DigitalOceans prices are quite fair for the power under the hood.

Search for Plants and Nurseries | NurseryPeople (
10 upvotes·8 comments·24.7K views

Around the time of their Series A, Pinterest’s stack included Python and Django, with Tornado and Node.js as web servers. Memcached / Membase and Redis handled caching, with RabbitMQ handling queueing. Nginx, HAproxy and Varnish managed static-delivery and load-balancing, with persistent data storage handled by MySQL.

What is the technology stack behind Pinterest? - Quora (
8 upvotes·448K views
Avatar of tabbott
Founder at Zulip·
Shared insights
nginxnginxApache HTTP ServerApache HTTP Server

We've been happy with nginx as part of our stack. As an open source web application that folks install on-premise, the configuration system for the webserver is pretty important to us. I have a few complaints (e.g. the configuration syntax for conditionals is a pain), but overall we've found it pretty easy to build a configurable set of options (see link) for how to run Zulip on nginx, both directly and with a remote reverse proxy in front of it, with a minimum of code duplication.

Certainly I've been a lot happier with it than I was working with Apache HTTP Server in past projects.

Deployment options — Zulip 1.9.1+git documentation (
8 upvotes·141.9K views
Avatar of sgbett
Managing Director at Limited·

In 2010 we made the very difficult decision to entirely re-engineer our existing monolithic LAMP application from the ground up in order to address some growing concerns about it's long term viability as a platform.

Full application re-write is almost always never the answer, because of the risks involved. However the situation warranted drastic action as it was clear that the existing product was going to face severe scaling issues. We felt it better address these sooner rather than later and also take the opportunity to improve the international architecture and also to refactor the database in. order that it better matched the changes in core functionality.

PostgreSQL was chosen for its reputation as being solid ACID compliant database backend, it was available as an offering AWS RDS service which reduced the management overhead of us having to configure it ourselves. In order to reduce read load on the primary database we implemented an Elasticsearch layer for fast and scalable search operations. Synchronisation of these indexes was to be achieved through the use of Sidekiq's Redis based background workers on Amazon ElastiCache. Again the AWS solution here looked to be an easy way to keep our involvement in managing this part of the platform at a minimum. Allowing us to focus on our core business.

Rails ls was chosen for its ability to quickly get core functionality up and running, its MVC architecture and also its focus on Test Driven Development using RSpec and Selenium with Travis CI providing continual integration. We also liked Ruby for its terse, clean and elegant syntax. Though YMMV on that one!

Unicorn was chosen for its continual deployment and reputation as a reliable application server, nginx for its reputation as a fast and stable reverse-proxy. We also took advantage of the Amazon CloudFront CDN here to further improve performance by caching static assets globally.

We tried to strike a balance between having control over management and configuration of our core application with the convenience of being able to leverage AWS hosted services for ancillary functions (Amazon SES , Amazon SQS Amazon Route 53 all hosted securely inside Amazon VPC of course!).

Whilst there is some compromise here with potential vendor lock in, the tasks being performed by these ancillary services are no particularly specialised which should mitigate this risk. Furthermore we have already containerised the stack in our development using Docker environment, and looking to how best to bring this into production - potentially using Amazon EC2 Container Service

7 upvotes·251.4K views