4 posts tagged with "starthub"

As a part of my work on Starthub, I found myself having to think of a go-to-market strategy. However, given that Starthub is essentially a platform to deploy generic actions, I would first need to build the some useful actions one by one. This might end up costing me a lot in terms of time and effort, because I have no clear idea of what kind of actions would be actually interesting to users. Given that an action could be pretty much anything, from a single API call to the deployment of a en entire stack, I probably need to focus on action bringing a lot of value in a single transaction to the user. Are there any "ready-made" actions that I know that, for a fact, my users would find useful? Maybe the deployment of an existing open source project could be what I am looking for. In fact, many open source projects are already have a loyal user base, an already a well-defined scope and are painful to deploy. Instead of building full-fledged applications myself, I could just focus on making it simpler to deploy existing ones.

Picking an open source project​

There are thousands of open source projects out there. How to pick one? If we think of the pain of deployment as a crater, then the bigger the crater, the greater the value added by Starthub. In this scenario, the crater for an open source project will be defined through:

• width, which is its popularity. This is measured as the "number of stars on Github" (I know this is a debatable metric, but it's an acceptable proxy).
• depth, which is the complexity of its deployment. This is measured as the number of cloud primitives needed for the project to be deployed.

It does not take a lot of searching to find out that the biggest "craters" are represented by those open-source projects that have been gaining massive popularity lately. Among the others, Supabase (90k+ Github stars) and n8n (160k+ Github stars) quickly come to mind. Let's focus on n8n, the most popular one. If we look at the docs, there are several solutions to deploy the simplest, single-node configuration of n8n. That's great for small and hobby deployments, but not for production-grade, horizontally scalable deployments. In fact, the docs also offer documentation about queue mode, which allows a much more robust, scalable configuration.

Now, while it's great that n8n also takes into account the needs of power users, the documentation is quite lengthy to read, and, like it often happens, it leaves a lot of guess work up to the user. Could this be a good wedge to promote Starthub?

A different approach to deployments of open source projects​

While reading up on forums, I have come across a radically different approach to deploying open source projects that has become increasingly popular lately: Railway. I found Railway very interesting because it chooses different tradeoffs. Starthub tries to be as unopinionated as possbile and hands over full control to the user. In this way, it ensures that any edge case can be potentially handled (think the creation of API keys through a web UI of a platform that offers no APIs for it). However, it also adds complexity, and makes it harder to package actions. On the other hand, railway instead focuses on simplicity in exchange for freedom and security. In fact, Railway lets you deploy a production-grade configuration of n8n with a single click, but it assumes you are ok with never leaving its walled garden.

More incumbents​

Several incumbents seem to have adopted a similar approach to Railway;

• dev.sh, which is the open source version of Railway. Besides hosting your stack, dev.sh makes it possible to deploy the same stacks your own cloud, which basically turns it into a horizontal-first of Coolify or CapRover.

• Dokploy

• Elestio also let you host open source projects on the cloud, but without a focus on the

• Public cloud providers themselves have started offering tools to deploy open source projects with a single click.

Even more alternatives already available: Northflank, Render, Sliplane and others, but, since the focus of this article is about general trends, I will let them aside for the time being.

Takeway: we are moving up the stack​

While up until a few years ago we had to install open source projects and, more generally, applications manually on a VPS, we can now instantly install a horizontal configuration of said projects, with the ability of scaling each of the required components (db, vm, etc) manually. In a sense, a new layer seems to be emerging in the world of cloud computing, which solely focuses on the horizontal, scalable configuration of applications.

It is interesting to notice that the managed solutions we mention all rely, in a way or another, on containerisation. Cloud providers like Fly.io and Digital Ocean have been offering managed container solutions for a few years now. It sounds like

Where does Starthub stand then?​

Rather than focusing exclusively on deployments, Starthub is more of a swiss knife that can be used to perform arbitray tasks, among which deploying cloud architectures. It can be useful in cases where:

• A user never wants credentials to be shared with a third party (the sovereignty wedge)

• A user needs assurance of zero lock-in

• A user needs to deploy arhitectures across multiple cloud providers

• A user needs to automate manual configuration steps when deploying a cloud system

What's next?​

I wonder whether the next evolution of this trend could be the ability to compose stacks on the cloud in a Lego fashion. Railway and dev.sh are already sort of hinting at this through their UIs, where, if we sprinkled a bit of AI, we could probably get some meaningful autowire functionality to hook services into each other as soon as a new one is dropped into the canvas.

I can think of these future challenges:

• How to streamline the deployment of application updates?

• How to allow for additive, manual changes in an existing cloud configuration?

Over the past weeks I have been spending a non-negligible amount of time working with Supabase, a platform for backend development that has exploded in popularity in the recent years. Sitting on top of Postgres, Supabase uses classic SQL dumps to dump and restore a database schema. SQL dumps are not just snapshots of a database, but can be seen as a way to package the entire business logic of a company. At the same time, in one of my past blog posts I explored the idea of a top-to-bottom approach to building software, where an entire system could be deployed with a single command independently of the amount and complexity of its components. The question needs then to be asked: could SQL be the right tool to package entire systems, so they can be exchanged, traded and deployed in a standardised way? And, if not, what would such a tool look like? What would be the best level of abstraction to work at?

Over the past few months I have been thinking quite a bit about what a tool to deploy stacks of arbitrary complexity should look like. I have already written two blog posts about the rationale and best level of abstraction to implement it. So far, it looks like some kind of orhestration engine powered by Docker/WebAssembly. This would allow to package systems (frontend, backend, any kind really) of arbitrary complexity, potentially allowing to run UI-based configuration steps automatically. This is far from a complete model though, and many questions are still unanswered.

The company I currently work for offers a software platform to manage solar mini-grids. From a user's perspective, the platform consists of an admin panel and a suite of mobile-first web apps that our customers use to manage their solar mini-grids. It is a fairly standard IoT system: a storage layer (Postgres, Timescale and S3 are the main tools), a view layer (Vue web apps) and a business logic layer, consisting of a set of NestJS services for timeseries data and financial transaction processing. The schema is also nothing new: a set of tables to track the state of energy meters, process inbound and outbound commands from and to devices on the field and some RBAC tables were some of the center pieces.

Yet, it took us about a year to reach a production-grade setup. RLS rules, social login, embedding of a Grafana charts in the frontend, setting up a timeseries database a double entry accounting system took us months to get right. During that year, I often wondered about a faster, simpler way to get started from a ready-made, use-case-focused template instead of rebuilding everything, once again, from scratch. After all, our system was not too different from, say, one of those fleet-tracking systems that are commonly offered in the market I guess?