explaingit

deis/deis

5,999PythonAudience · developerComplexity · 4/5Setup · hard

TLDR

An archived (retired 2017) self-hosted Heroku-style deployment platform built on Docker and CoreOS, kept as a historical reference for container deployment patterns before Kubernetes.

Mindmap

mindmap
  root((deis v1))
    What it was
      Self-hosted PaaS
      Heroku-style workflow
      Push to deploy
    Built on
      Docker containers
      CoreOS Linux
      Fleet scheduler
    Ran on
      AWS and Google Cloud
      Bare metal
      Local Vagrant
    Status
      Retired 2017
      Historical reference
      Replaced by Kubernetes
Click or tap to explore — scroll the page freely

Code map

Detail Auto

An interactive map of this repo's files and how they connect — its source is parsed live in your browser. Click Visualize to build it.

filefunction / class

Things people build with this

USE CASE 1

Study how pre-Kubernetes container deployment platforms handled push-to-deploy workflows

USE CASE 2

Understand the Docker-plus-CoreOS era architecture for building your own internal platform

USE CASE 3

Reference the cluster scheduler and routing layer design when evaluating modern PaaS alternatives

USE CASE 4

Trace the design decisions that led to the Kubernetes-based Deis Workflow successor

Tech stack

PythonGoDockerCoreOSShell

Getting it running

Difficulty · hard Time to first run · 1day+

Retired and unsupported since 2017, do not use for new projects, repository exists for historical study only.

License terms not specified in the explanation, check the repository directly.

In plain English

Deis v1 is an archived open-source platform that let you run your own app-hosting service on your own servers. Think of it as a private version of Heroku: you give it a server or a cluster of servers, and it handles the work of deploying, scaling, and managing your applications. The project was built on Docker (a system for packaging applications into self-contained units called containers) and CoreOS (a minimal Linux operating system designed for running containers at scale). The command-line workflow was modeled after Heroku, so developers who already knew that style of deployment could adapt without learning an entirely new mental model. The appeal was control over your own infrastructure. Rather than paying a cloud provider to host your apps on their terms, you could run the same kind of push-to-deploy workflow on servers you owned or rented. Deis v1 could be installed on public clouds such as AWS or Google Cloud, on private servers, on bare metal hardware, or even on a local development machine using Vagrant for testing purposes. Deis v1 is no longer maintained. The project was officially retired in 2017, and the repository now exists only as a historical reference. The README makes this plain: the code is unsupported. Active development moved to a successor called Deis Workflow, which the team rebuilt on top of Kubernetes instead of CoreOS. The README itself links to that project as the replacement. If you are studying the history of container-based deployment platforms, this codebase shows how teams approached the problem in the Docker-plus-CoreOS era, before Kubernetes became the default approach. For any new project, you would not want to build on this archived code.

Copy-paste prompts

Prompt 1
I am researching the history of container orchestration platforms. Explain how Deis v1 handled app deployment using Docker and CoreOS Fleet, and what problems it solved before Kubernetes became standard.
Prompt 2
What was the Deis v1 architecture for routing traffic to deployed apps, and how does it compare to how Kubernetes ingress works today?
Prompt 3
I want to understand why the Deis team decided to rebuild on Kubernetes for Deis Workflow. What were the limitations of the Docker-plus-CoreOS approach that drove that decision?
Prompt 4
Walk me through how a developer would have deployed a Node.js app on Deis v1 using the Heroku-style git push workflow, from adding the git remote to seeing the app live.
Prompt 5
How did Deis v1 handle scaling an app to multiple instances, and what component was responsible for distributing those instances across cluster nodes?
Open on GitHub → Explain another repo

← deis on gitmyhub — every repo by this author, as a profile.

Verify against the repo before relying on details.