DigitalOcean App Platform

I was really excited about this when I got the email a few weeks ago with a beta invite but after two minutes I realised I’d be unable to use it, and still can’t now it’s launched...

Why oh why is GitHub now considered the single place where code lives? Even as alternative providers gain in popularity.

It’s really sad to see DigitalOcean requiring this for some reason.

Please either allow use of arbitrary Git repositories (e.g. self-hosted GitLab in my use case) or provide a stand-alone CLI tool to enable deployment of anything, like Firebase does.

Disappointing so far.

Maybe 95% of people use it and it made sense to them, who knows?

I hope this is in the backlog, because I'm not switching for GitLab for this.

From article:

> You can deploy the source code directly from your GitHub repositories (support for GitLab and Bitbucket is coming soon).

Naming specific git hosts suggests it may not be available on "arbitrary Git repositiories" in the near future, but looks like they are at least planning to broaden the options for where to have your code live

Such a weird approach that seems repeated by many. Instead of building something general that works for most cases and is easier to implement, they focus on specialized cases of specific SCM platforms.

If they started with support Git Remotes and then supporting specific platforms, they would have covered all use cases from the get-go, albeit with slightly poorer UX.

But instead they chose to only support specific platforms, missing plenty of people who actually want to use this, but can't.

Git remotes is certainly not "easier to implement". You need to have ssh infrastructure setup to receive the repository, deal with key management, provide the user some way to input ssh keys, etc. Contrast that with GitHub web hooks + API and I can see why they didn't bother.

I bet GitHub covers the vast majority of their target users.

You can use the [doctl](https://www.digitalocean.com/docs/app-platform/references/co...) CLI along with an app specification yaml to deploy from your self-hosted GitLab.

The App Specification supports a normal Git repository. However, I can see how this might be a problem if your repository is private as there are no configuration options for auth.

Git supports a number of transfer protocols[0]. There's no requirement to support SSH in order to implement pulling from generic repos.

[0]: https://git-scm.com/book/en/v2/Git-on-the-Server-The-Protoco...

Yeah, but that’s how the 80%-rule of “good enough” entrenches the bigger actors, ejecting the otherwise perfectly fine alternatives. It’s the power law that makes the rich richer (and turning everything in a mess of managment-driven kludges.)

You really don't need all of that just to support pulling a Git repository, private or otherwise. Adding async nature to a technical problem (webhooks + API as you suggest) immediately makes a otherwise sync problem way harder and error prone.

> I bet GitHub covers the vast majority of their target users.

Sure, but if they added Git, they would reach everyone using GitHub + everyone else who is using Git.

With powerful primitives you can build powerful abstractions, Git is one of the examples of this. But if you instead focus on a single-use case (using GitHub), adding the rest becomes a lot harder, than if you started with the basics. Something 90% of product people in SF seems to have forgotten lately (or never learned?)