Show HN: Heroku Alternative for Python/Django apps

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)

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.

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.

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

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!

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.

Admittedly, this works great for clusters of 1-10 machines. There's definitely some missing stuff that's hard to add for larger deployments.

But, I'd venture to say that most of Dokku's target audience doesn't need to worry about scaling past a couple of servers.

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.

So I'm not sure that I follow you.

We aspire to build a convenient service for Python/Django and there is a long road ahead.

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.

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.

Woops, that is a pretty big beast.

2172 lines of code in 98 files.

I would not feel comfortable by starting from a base that is already this complex.