I have been following this space alot.
Heroku like deployment spaces have exploded recently partly because people miss that experience, partly because buildpack is opensource[1], partly because we have gone through a techshift where it is pretty easy to emulate that.
There are two broad categories - 1. Dokku's of the world, one VM (very recently tried adding multi node) and then more recently getporter.dev[2] and okteto[3] of the world that is trying to replicate heroku on kubernetes.
One of things, I noticed is that, It looks really cool at first look but every organisation has their own complexity in deploying stuff. It is an integration hell, you have to provide white glove treatment to all customers and eventually you have a hard time scaling.
We tried it too, and what we noticed if you have to go an enterprise and sell, you start doing leaky abstraction. It works really well for early stage startups but once they have the money you prefer something more customizable and robust solution.
This project looks cool. I do not want to discourage anyone but again, it is a red ocean out there.
The problem is the layering of the abstractions. Having PaaS on top of Kubernetes in a way that you move down to a more powerful primitive is going to be the most scalable.
What happened in the public cloud space was a disparate set of services which made the choices really costly. Azure went in heavy on PaaS while AWS was focused on VMs. The easy adoption and migration was on AWS. K8s seems like a reasonable abstraction that reduces the cost of these decisions because people seem to agree that K8s is a reasonable base.
Being able to slide on a compatible PaaS layer shouldn't negate that K8s investment, and make it easier to adopt for some organizations, or parts of those organizations. But, I wouldn't argue that we are the point where that layer is mature.
I do not agree with you. PaaS abstraction becomes super leaky on top kubernetes as you start solving real world problems.
That is one the first mistakes newly formed platform teams in a company makes, abstracting infrastructure. Happy flow of PaaS on kubernetes is great. It is magical to certain extent. But negative flows is a really mess. The customer no clue why certain things do not work and you as a engineer had no clue that this would have happened.
Secondly, the amount breaking changes you have deal with as a result of abstraction is crazy. People pushing code does not care. It is basically moving complexity from one place to another.
> The following functionality has been implemented: Deployment and Service annotations, Domain proxy support via the Nginx Ingress Controller, Environment variables, Letsencrypt SSL Certificate integration via CertManager, Pod Disruption Budgets, Resource limits and reservations (reservations == kubernetes requests), Zero-downtime deploys via Deployment healthchecks, Traffic to non-web containers (via a configurable list)
We're[1] in a similar space and our winning strategy has been to provide white-glove onboarding to get our customers environment up and running. It's part of doing something that doesn't scale (easily) but it also allows us to figure out what else we can automate away to increase pace on these onboarding.
The product looks great. I don't want to discourage you guys, I am failing to see a moat as compared to you guys and lets say getporter or others in the spaces. Funny enough you guys are also YC company.
Product with a high touchpoint I think does not scale this early on as a company.
For reference, Porter as a product is doing great because I think they have invested a lot in building a community. I think that works to certain extent as at scale community helps each other.
But, just beware of the fact that market cap is actually pretty small. You have enterprise competition from VMWare Tanzu and others. On the cloud space, you have digitalocean's app deployment thing, AWS has app runner. I have at least seen over 20 companies doing pretty much the same thing. Just a thought.
Looks very interesting, will have to give it a shot!
I made an open source “dashboard” for dokku that tries to give you Heroku ease of use with the cost of a single server.
Basically you run one script on the server and it deploys a dokku app which manages the deployment of additional dokku apps. Gives you GUI access to deploying new apps, changing env variables etc.
Would love feedback from anyone looking for an easy way to deploy dokku apps regularly.
Long-time dokku user here. This seems interesting.
How nicely does this play with more complicated things, like configuring ports for SSL, or using additional Dokku plugins?
How about things like configuring the container network and things like upload size variables, or the wait time when deploying, etc.?
Haven't worked on this in a while so can't exactly remember but focuses more on the MVP functionality. Should be easy enough to add anything you could traditionally do through SSHing into the box though.
Can you talk a bit about the security model? Appliku requires an AWS user with:
AmazonEC2FullAccess
AmazonEC2ContainerRegistryFullAccess
AmazonEC2ContainerServiceFullAccess
AmazonS3FullAccess
That's a lot of permissions into my AWS account. What are some easy ways to contain the damage that could be done if Appliku has a bug or the creditials are compromised?
I would recommend dedicating an entire AWS account to this. Or, if you have a solid tagging strategy[0], you can craft your IAM policies to only allow Appliku access to resources tagged with a particular tag.
Separate account will be the best strategy. I prefer having separate accounts for every project. Hustle to login between them, but the best isolation that can be between projects.
If anyone is looking for a similar service to deploy Ruby/Rails apps, check out https://www.hatchbox.io from Chris Oliver. Unfortunately doesn't come with a free tier but worth every penny!
I would like to say that existence of Chris Oliver’s Hatchbox was initial inspiration and validation after finding which i decided to build Appliku. So, Thanks, Chris!!!
Hatchbox its an absolute lifesaver for my deployments... I cannot stress how helpful and well crafted it is... But every single day of my life I worry about what is going to happen to all my infrastructure if something were to happen to Chris/HB...
Thanks for the support! Glad you've been enjoying Hatchbox. We're wrapping up v2 and can't wait to share it. Upgrading to Caddy for the web server has been wonderful.
Yes, I can def-ly see it is way better. Question here, as far as i understand Caddy is a paid product, how its licensing works while deploying on customers servers?
This looks sleek, but I’ll ask the obvious question: Why use this over Heroku? I couldn’t find a good answer to that question from a quick look at the website, aside from maybe the fact that it uses AWS and Digital Ocean.
It is easy to start on Heroku. With one app, one process.
When you have multiple apps and several processes there is a way to reduce costs and not loose in convenience.
$10/mo droplet can hold plenty of apps and it is still $10/mo. If you don't need a production grade Database – Appliku has them at 0 cost.
Back in a day I moved several of my side projects to Heroku. I was happy until i received a $90+ invoice by the end of the month. Now a $10/mo droplet holds even more projects for me.
Thanks for the response. My two cents: price is not the thing that I would compete on. For any "real" business, the cost of Heroku is negligible compared to its benefits; a few hundred dollars per month in savings is just not enough to convince most companies to migrate to a completely new service that isn't as battle tested and has fewer features. At the same time, I'm not convinced you could make any significant amount of money tailoring your service to side projects.
With that said, I think you have a great product and could probably make some decent money by offering some combination of niche features. Ideas off the top of my head:
* Integrated metrics. Since you're primarily targeting Django apps, it should be feasible to collect health/performance stats from the apps and display them in a simple dashboard. You don't need to offer very much here; most companies would be more than happy with basic stats related to response times per route, although SQL query times would be really neat to see.
* Automatic scaling for your Python projects. If you could apply the same ease of deployment to horizontal scaling, that would be really valuable.
* Easy integration with AWS services like S3, SES, and SNS. You could do this in a number of ways. One idea is to provide a set of Django libraries that, for instance, makes sending SMS messages super simple, with no configuration needed when used via Appliku. Or you could integrate with existing libraries and just remove the configuration step for the developer.
With at least one of the above (or some other differentiator), I could see Appliku taking off. In any case, you have a great product, and I wish you the best of luck!
So first I am thinking what is the best way to offer scaling. There are so many ways how it can be done and in other comment threads there are hot debates happening about that. It is still an open question.
I was thinking about tailoring more features for django too. Not only price is different, but I picked Django for a reason. It is a great suggestion about metrics per route. I haven’t thought about it before.
Integration with AWS services – Yes. That’s why initially i had a wide range of recommended Policies to include in AWS credentials. My goal was to make automation around creating not only app but all auxiliary services without the need for user to deal with AWS manually.
basically let appliku orchestrate 3rd party services in order to get the “recommended setup”.
So not only I have limited positioning to Python/Django niche, but next tools that will appear will make people using this popular framework way happier by taking away their pain.
You can do Dokku, you can setup dokku and deploy apps with dokku. no problem.
But I wanted a solution where I don't need to remember anything DevOps while writing/shipping my apps.
I also added a generous free plan that allows all features. Then AWS has free credits so one can start their next big thing without expenses and not learning a single thing about deployment at all
Heroku is a general apps platform. This seems to be tailored specifically to Django/Python (with the option of using your own Dockerfile so could deploy anything). One could easily imagine that the performance and stability should be a lot higher than with Heroku. If you're a Python-only shop, it might make more sense.
> One could easily imagine that the performance and stability should be a lot higher than with Heroku.
No, I can’t imagine that. Why would performance be any different? I imagine most of these kinds of solutions use Docker behind the hood anyway, so they’re likely to be identical.
That makes more sense, but the deploy cycle is already really fast with Heroku. I'm not sure if there is very much value in trying to shave off a few more seconds.
Depending on your requirements build ties in Heroku can be quite long. One app i’ve recently observed take 7 minutes to build because it always had to build both JS and Django parts(buildpacks for both were executed every time). We made it way faster with custom docker file that used caches and often built under 40 seconds. i am not saying that is not doable in Heroku, but would take more effort.
only if developer/devops/admin time is free and for most it isnt. if 60 vs 250 /month is a breaking factor for you and your use case: go for it. if you need the software deployed to make real business it just doesnt matter.
> if you need the software deployed to make real business it just doesnt matter
No wonder AWS can get away with the prices they have since people like you (and many more VC funded startups) simply have zero care about the price.
For people who run "real" businesses (meaning you need to have a larger income than expense [meaning, everything not VC-funded]), price is always a part of the calculations, even when it comes to hosting.
having something that specific, tailored for dynamic language, seems like overkill
i'd undestand if it was for something highly performant and hard to deploy
Maybe, but maybe not. If you're using Python/JavaScript and have a ton of dependencies, most of your deploy-time is gonna be spent downloading dependencies. If the host you're using is specifically setup for Python/JavaScript, they can run a registry mirror with 100% of the packages right next to the host, and remove basically most time spent downloading the packages.
Same goes for other time-consuming activities like code coverage or even running the tests. If the applications running on the platform are somewhat heterogeneous, then you can start doing really aggressive performance work.
Hey Congrats on launching this. I really hope it'll grow.
Here are my 2 cts.
I've used dokku for this, running Django, for years and recently I moved a customer over to use the digital ocean app platform.
There are a couple of things I find important when evaluating these platforms that I didn't see on the site:
- is there database fail over with the multi server strong and powerful plans?
- does appliku maintain the underlying servers and database?
- is there monitoring?
At the moment databases in Appliku are best fit for non-production environments. So while you can enjoy easy and great deployments of your apps, I am not ready yet to compete on the production databases front. So no, we don't offer fail over or even backups at the moment. Backups are in plans, but more advanced features for databases is not even in backlog.
Re: production-quality DBs, it's its whole own ball-game.
Rather than getting into all of that, your time here might be better spent here finding DBaaS services that host on the same clouds Appliku deploys to, and partnering Appliku with them to guarantee predictable network-transit peering to the clouds your users are launching on; probably by setting up the install-time UX flow so that that DBaaS choice is made early in the setup flow, and constrains further choices (i.e. user chooses DBaaS X; Appliku knows what AZs it exists in in each cloud, and restricts user to deploying the app to those same AZs in order to ensure free transit.)
In other words, do the backend work Heroku does to add a new DBaaS "add-on" partner, but without reselling/wrapping the resulting service, instead just giving a UX to bind to it.
One thought I have in mind is ability to provision AWS and/or Digital Ocean managed DB offerings so you don’t have to leave appliku interface to get a production grade DB.
But Appliku will keep being deployment solution for apps.
As a long-time Dokku user, have you done any multi-server deployments or just stayed to a single server? I'm happy with Dokku for side projects but would be interested in what Dokku users use when they need to move up to a multi-server setup.
I am long time paid customer of Appliku. I've built a SaaS (https://unicornplatform.com) and before was hosted on Heroku. Migrating to Appliku saved me $400/mo in cloud costs.
My app is React & Django and it works like a charm on Appliku.
I'm learning to run a Django app and have been toying with deploying to DigitalOcean. Decided on this to learn atleast some generic DevOps things as opposed to too-proprietary (Heroku) and too-expensive (AWS). There's a decent amount of Nginx, Gunicorn, and Postgres things that seem to need to be scripted, and I'm still not sure how to quickly reproduce the server automatically (scripts?) and replicate the server environment on my Mac without adding Docker/Podman to the mix (running Django app on my Mac and deploying to Ubuntu server env could cause issues unknown locally).
How does Appliku help address these issues?
Edit:
Also, is Appliku itself deployed with Appliku? If so, if Appliku experiences issues, do you have a quick method of deploying the fix outside your usual deployment?
Thanks. When people say they use Docker, there seems to be several different ways. Are you using Docker Desktop (Mac/Linux?), docker-compose, Podman, or something else?
DO Apps platform in terms of pricing is as bad as Heroku's offering. They charge per instance of the process and it becomes pretty expensive. Appliku helps to reduce costs by putting processes on a single server.
With Heroku Config Vars sync feature one of the customers managed to save around $7k/mo on fat Dynos that are insanely overpriced in Heroku.
So while DO Apps platform will definitely have their target audience, Appliku allows to save a lot of cash.
We tried Heroku, and that was expensive.
We tried deploying manually on AWS but it took a lot of time with a devops freelancer.
Got sold on Appliku and haven't had to think about infrastructure and deployment at all. We also survived for a long time on the free plan, until we decided to have a separate server for staging environment.
Works pretty well. Never had to learn anything about servers and SSH.
> Create as many instances of Postgres, PostGIS, Mysql, Redis and RabbitMQ as you want. They are hosted on your servers and we don't charge extra for them.
I'd love to learn more about this, I couldn't find any details. Is there a page with more information? Specifically, I'd like to know more about backups and upgrades.
At this moment we are not fighting for the niche of Production grade databases with failovers and all these valuable things.
The feature to back up at least postgres is planned, fail overs , replication, etc is not even planned yet. There are companies that have whole departments working on managed DB offerings, sadly – we don't. yet :)
The existence of Heroku/Appliku etc (and my personal experience) suggests that setting up web apps isn't hassle free.
Maybe the fix for this would be to have a language/library combination designed from the ground up to make it as easy as possible?
So for example, the language would come as standard with:
- a web server for production use
- a web server for development use
- a built-in SQL database
- a built-in NoSQL database
- a web server library
Then, as all the components for the system would part of the language's standard library/environment, the difficulty of configuring/running a server (such as a web server) on another machine would be limited.
I would correct the last part. Appliku is an automated devops as a service. Heroku is selling you a very much overpriced complete service. And that's where Appliku comes in as a way to fight insane costs.
But yes, setting up a server is not super hard. Doing it often and with convenience that's where improvement is needed compared to doing it manually.
I think your project is cool, but deploying an application to a server on `git push` is not devops. Heroku is selling managed servers and databases with easy deployment, you're selling easy deployment to unmanaged servers and databases.
If I understand you correctly, you say that setting up a server isn't hard, but then you seem to imply that it's hard enough that you might want to employ a team of people to do it, which seems pretty hard to me.
Setting up a server and database is not hard. Maintaining and scaling it is. I don't want to use my valuable time on these things, so Heroku is worth the cost. People who say Heroku is expensive are not in their target market -- businesses who want to avoid their team unnecessarily spending time on infrastructure instead of product.
Heroku is much, much cheaper than 1) me spending my time on these things, or 2) hiring a capable engineer to do it for me. It's build vs buy. I'd rather buy.
But that's not to say I'm not interested in a Heroku alternative. But it needs to be a *real* alternative. :)
I think you're missing a big part... getting it hosted on the internet, stable, and scalable. Can't do that from your laptop no matter what the language environment comes with.
This just needs a VPS, running a popular OS such as Ubuntu.
> stable
This is important, I agree.
> and scalable
The scalable part doesn't matter, since it's premature optimisation, which is the root of all evil.
Once the project is used by enough people that it cant run just on one dedicated server, then you'll hopefully have enough revenue coming in from it to make it scalable.
> Can't do that from your laptop
A VPS would typically have less power than a laptop.
Scalability does not only refer to the setup being able to serve a lot of users, but also to the development processes being scalable. Setting up and maintaining dev and demo environments needs a scalable process for example from the day you have a junior person on the team that cannot handle all the complexities by herself. Or, if you start to have multiple internal dev environments to evaluate different technology choices that might impact long term development.
We‘re mostly JS based, and even though everything is dockerized, it still sucks to onboard people and manage multiple deployed branches on AWS EC2.
Also every provider offers different things, at different costs, etc. So it is up to providers to build solutions that are easy with a given language or framework.
We aspire to build a convenient service for Python/Django and there is a long road ahead.
So with Heorku, if an app has one dyno and that dyno doesn't receive any traffic in 1 hour, the dyno goes to sleep. Does Appliku have a similar thing or does it stay online longer?
I must have been living under a rock but I don't fully understand the appeal of these types of services if I have to run my own server anyway.
What I'm thinking is that it only saves me the initial setup of a web server and a git hook and perhaps a DB (which is one tutorial away for anyone with basic technical skills) after which deployment would just mean a git push. What am I missing?
In a nutshell it is delegating all this manual work to a service.
I was happy with manual deployments for a while too, until i got fed up with this activity.
It is just a question of quality of life, automation.
Also, yes - there are tutorials, but what if you are not willing to spend time learning it even if you have tutorial?
Most of developers have a very high pain tolerance for manual tasks and search for yet another tutorial how to do X by themselves instead of delegating a task to some app or service.
This is very interesting to me. I'm essentially a one man devOps team at a small web agency hosting multiple client websites mostly based on Django.
One question; what do you do about compiling and transpiling Javascript? Right now it's done via webpack in the local environment and then pushed out to S3/CDN.
I have a question. Are you deploying it to your servers/cloud accounts or clients’ accounts?
Regarding your questions: it is responsibility of the app to build and upload the static assets where needed.
If you want recommendation what to do, I’d say you’ll need a custom dockerfile, install node, run webpack in there and collect static.
If you are not using collectstatic in that process then given the lack of details I’d say why are you doing it in the same repo at all. But again – you provided very little details.
So if it is a website(server rendered pages, SEO is important,etc) - you should have node and do optimisations before pushing to s3.
If it is an app (RIA,SPA) then I’d say don’t mix frontend and backend. Decouple it and ship frontend separately.
Appliku Interface is built and served with Netlify. I still remember those dark times when I had frontend inside the main repo. It was largely inconvenient.
Either way happy to chat about your issues in our discord server. I am more than happy to help you figuring this out.
Yes well separation of frontend/backend is of course a good idea, but most of the projects are mostly django templates with some React sprinkled on top to make interaction and interfaces nicer. It's also a good idea if you have just a single project or a few of them.
I'm talking about maybe 30-40 projects with django as base so it would make my job so much more complicated if I would split them all up in repos.
The frontend code is mostly isolated but is shipped in the same repo to be built and distributed for django to find.
So your answer about a custom dockerfile is probably what would be needed.
Congrats on shipping! I could see myself using a service like yours, and bringing my own server is perfect as I can adjust and scale it up/down as needed.
I'm thankful that Heroku prices are that extreme because it made me learn how to deploy and run everything by myself back in the day.
While I know how to deploy myself I am fed up with that. Especially when it comes to a new project. There are so many places where you can screw up with a typo or stuff like that.
So while I know how to do it by myself, I don't enjoy doing that and that's how the project got started.
Does anyone know of a FOSS app to help setup something similar to managed databases w/ Postgres/Mongo, but with ease of use just like AWS/DO have? Handling backups, scaling with minimal user intervention yet self-hostable?
Is there any service that I can just upload a py file and a requirements.txt and it will just run? No bundling, packaging, git, cli, etc. Not even for a web app but main use case is to host a Discord bot.
Other than that – no specific requirements. Drop me a line in contacts on our site if you need any help. Or in our Discord Community: https://appliku.com/discord
One of things, I noticed is that, It looks really cool at first look but every organisation has their own complexity in deploying stuff. It is an integration hell, you have to provide white glove treatment to all customers and eventually you have a hard time scaling. We tried it too, and what we noticed if you have to go an enterprise and sell, you start doing leaky abstraction. It works really well for early stage startups but once they have the money you prefer something more customizable and robust solution.
This project looks cool. I do not want to discourage anyone but again, it is a red ocean out there.
[1] https://buildpacks.io/
[2] https://www.getporter.dev/
[3] https://okteto.com/