porter

t. If people would like to use our cloud offering because it reduces the headache for them, they should do so. If they just want to run our service and manage their own PostgreSQL, they should have the option to do that too. Based on all of this, here's where we land on things: 1. Everything we've built so far has been 100% MIT licensed. We'd like to keep it that way and make money off of Hatchet Cloud. We'll likely roll out a separate enterprise support agreement for self hosting. 2. Our cloud version isn't going to run a different core engine or API server than our open source version. We'll write interfaces for all plugins to our servers and engines, so even if we have something super specific to how we've chosen to do things on the cloud version, we'll expose the options to write your own plugins on the engine and server. 3. We'd like to make self-hosting as easy to use as our cloud version. We don't want our self-hosted offering to be a second-class citizen. Would love to hear everyone's thoughts on this. [1] https://hatchet.run [2] https://github.com/porter-dev/porter [3] https://www.elastic.co/blog/why-license-change-aws

ns: it's worth mentioning that Porter is also open-source (repo here: https://github.com/porter-dev/porter). If you want to use Porter purely as a UI on top of your own infrastructure that you are managing yourself, you are more than welcome to take it out on a spin with our OSS repository!

/www.workatastartup.com/jobs/45970 - Full-stack Engineer: https://www.workatastartup.com/jobs/43716 Please apply by sending an email to jobs [at] porter [dot] run or applying through https://www.workatastartup.com/jobs/43716.

/www.workatastartup.com/jobs/45970 - Full-stack Engineer: https://www.workatastartup.com/jobs/43716 Please apply by sending an email to jobs [at] porter [dot] run or applying through https://www.workatastartup.com/jobs/43716.

www.workatastartup.com/jobs/45970 - Full-stack Engineer: https://www.workatastartup.com/jobs/43716 Please apply by sending an email to jobs [at] porter [dot] run or applying through https://www.workatastartup.com/jobs/43716.

0, we were building a remote development platform for teams on Kubernetes (kinda like repl.it but for microservices in particular). This was a more enterprisey product and we got burnt out by the slow sales/iteration cycle (we had zero experience with sales, let alone enterprises). So we decided to pivot a few months after demo day. When we were struggling to get traction with the original direction, we learned a ton by talking to engineering teams that are using Kubernetes (k8s). One thing we noticed is that there's an increasing number of startups who start on a PaaS like Heroku and end up migrating to k8s later as their applications “grow out” of Heroku, due to constraints in networking, performance, security, etc. While Kubernetes is great, it incurs a ton of engineering overhead. For teams who don’t know k8s at all, learning everything from scratch is daunting and time-consuming. Even if there are devops engineers on the team who are familiar with kubernetes, adopting k8s slows down developer velocity because other developers always need the devops engineers’ help to troubleshoot the slightest application issues. While we were working on our previous product, we discovered that some companies even built internal development platforms (IdP) that are much like Porter, in order to help developers deploy and troubleshoot their applications without help from the devops engineers. Our goal with Porter is to create a platform that is truly as easy to use as Heroku, without compromising the flexibility of k8s. There are many self-hosted PaaS's that came before Porter, such as Flynn, Tsuru, Dokku, and CapRover, which were all created before Kubernetes changed the DevOps landscape. While these are great lightweight options for smaller projects, a PaaS built on top of the k8s ecosystem comes with many benefits such as scalability, stability, configurability and interoperability across cloud providers. We believe that k8s is the best system to deliver a PaaS on, and we’re not alone - many of the new hosted PaaS’s are also built on top of k8s, although that’s an implementation detail that is usually not advertised to the user. We want to not only deliver the PaaS experience on top of Kubernetes, but also give users full ownership/control of the underlying k8s cluster by running it in their own cloud. How it works: we spin up a k8s cluster in your own AWS/GCP/DO account and let you deploy and manage applications on it through a Heroku-like abstraction layer. For teams using a PaaS like Heroku, Porter can be a drop-in replacement that you don’t “grow out” of. And although our abstraction layer covers most use cases, we let those who want to customize go freely under the hood to interact with the underlying cluster. In each cloud provider, we provision the standard managed k8s offering (e.g. EKS/GKE/DigitalOcean Kubernetes), so the clusters we provision are perfectly compatible with kubectl and any other k8s tooling out there. It’s even possible to connect Porter to an existing k8s cluster—this isn’t the primary use case we’re building for at the moment, but we’d love to discuss it in the comments if anyone is interested. In terms of implementation, we’ve built Porter around the Helm ecosystem, and every application you deploy is packaged as a Helm chart. For those who want more visibility, we’ve built features like “devops mode” that lets you visualize and manage the Helm charts and its underlying k8s objects. We’ve published Porter to be fully open source under the MIT license. We provide a hosted version that is currently in open beta, but it's also possible to run Porter locally. It’s worth clarifying that on the hosted version, the applications you deploy through Porter still run in your own cloud. What is hosted by us is only the PaaS layer, not your applications. We plan to release a self-hostable version of the PaaS layer itself in the near future, packaged as a Helm chart. We do not support this yet because self-hosting the PaaS layer inevitably incurs devops overhead and requires some knowledge of k8s, and we are currently focused on those who just want the Heroku experience without having to deal with k8s in any way. In terms of pricing, we are still figuring out the specifics. Our goal is to not charge individual developers/small startups but instead draw revenue from larger teams based on usage, and with premium features that are geared towards collaboration. Existing PaaS’s like Heroku/Netlify have solid examples of such premium features - review apps, pipelines, and Role Based Access Control are a few examples that we also consider to be potential premium features on Porter. That said, we are currently focused on laying out the stable foundation of the platform, so these premium features are further down on our roadmap. Thank you so much for reading and we'd love it if you could give it a try: https://github.com/porter-dev/porter. We'll be hanging out in the comments to hear any ideas and feedback you may have. If you have any experiences related to what we’ve built, we would love it if you could share them below. Very much looking forward to learning from you!