Sovereign edge for everyone: What Hardpoint is, and where we're going
tl;dr
Our MVP is in public Alpha, go check it out!
The MVP addresses some key networking pain points with serverless workloads. Things that should be easy but aren't:
Safely connect a Vercel project to a database without changing your cloud provider or YOLO'ing firewall rules (more FaaS vendors coming soon)
Authenticate, authorize and observe PaaS/FaaS workloads based on zero-trust principles rather than old-school IP whitelists or other fixed constraints
think of it as Tailscale or NetBird for serverless.
However, our long-term mission is more ambitious: we want to make sovereign edge computing accessible to startups of any size from $0 ARR right through to unicorns 🦄
The break-up
Our thesis is that modern SaaS delivery is becoming increasingly fragmented, and that's not necessarily a bad thing. But the conceptual gap between zero-ops PaaS/FaaS products and traditional cloud infrastructure is creating an unacceptable amount of friction for growing startups with packed roadmaps.
This industry is being simultaneously buffeted by two antagonistic forces:
widespread adoption of AI, catalyzed by the maturation of vibe coding tools, backed by zero-ops PaaS products that run them; this is precipitating an explosion in edge computing
increasing concerns about data security & sovereignty, not just as top-down impositions from national bureaucrats, but from individual companies who want to jump on the AI bandwagon whilst capping downside privacy risks
It seems like a certainty at this point that the tension between sovereign compute and edge-native cloud computing will become one of the most important infrastructure debates of the next decade.
This tension tends to manifest itself most acutely in the interconnect between the two worlds: in the quagmire of network plumbing, load balancer rules and the many points in a request path where tenant-awareness has been retrospectively added to an existing SaaS application.
The combinatorial explosion of edge workload V sovereign region permutations is making this plumbing look increasingly archaic.
But I don't use serverless 🤷♂️
That may well be true, but on a long enough trajectory, you are almost certain to leverage some kind of edge compute primitive, if you're not already. Whether that's from a cloud provider or by unwittingly rolling your own; at some point, the odds are you will need to sit on the edge, and if you're simultaneously trying to win customers who need sovereignty, your architecture suddenly has to become significantly more complex to work around the internal contradictions of these two philosophies.
Hardpoint's long-term mission is therefore twofold:
Make it safe and easy to connect & route traffic in heterogeneous cloud environments
Make it simple for SaaS businesses to place data within sovereign boundaries, without sacrificing edge-native benefits
Or put another way: make sovereign edge architectures not just feasible, but natural.
PaaS: The Promise vs. The Pain
The modern PaaS experience has fundamentally altered the way that cloud software is shipped from 0 → 1. The growth models of major players have allowed indy developers to launch experimental products for effectively zero up-front material cost. It's also massively shortened the feedback loop by lifting most basic ops tasks into their opinionated platforms, meaning that product engineers can, for the most part, simply focus on application delivery. For trivial applications, serverless really does amount to zero-ops.
The isolation guarantees* you get with serverless PaaS also serve as the bedrock of vibe-coded output; in short, anything that Lovable or V0 spits out needs to run somewhere, and giving these apps their own walled gardens makes the risk of unintended behavior tenable in many cases. Combine solid execution boundaries with minimal ops workload and it makes sense that Vercel et al have become a compelling place to deploy and self-drive AI-generated applications.
The honeymoon normally ends when you have to deal with application state: most PaaS operators have made the strategic decision to deliberately not build their own stack of cloud primitives on top of AWS or wherever they run, instead leaving the market to fill in the gaps. In the common case of a database, you're free to spin up an RDS instance or use one of the growing array of serverless, zero[or at least minimal]-ops fully managed offerings. Vercel has a marketplace full of these to reduce the onboarding friction even further.
For many b2c startups, this approach may get you far, and we're certainly not criticizing the underlying tech; but there some down-to-earth problems (and a few bigger semantic ones) that can become deal-breakers when you compose a bunch of 'serverless' services together.
First up, the low-level stuff: you're not supposed to get hung up on which cloud provider and region your data and compute lives in when you go full-on serverless, which means that the connections between function and data store more often than not just go over the public internet. Yes, if you're lucky, you can get a fast path inside a VPC if your function & backend live in the same cloud (provided you're willing to pay), and yes, most FaaS vendors will rent you a fixed IP block if you need to gate origin access (once again, for more $$$). Either way, you lose the agility that comes with cloud agnosticism. With IP blocks, you're back to old-school topography-based access control.
Or, if we're honest, more often than not we eschew the static IPs and just YOLO the firewall rules with 0.0.0.0/0:
This is a shame, since a growing number of PaaS vendors support some kind of OIDC token federation, obviating the need for things like topology constraints (e.g. what IP address are you calling from?) or shared secrets.
Instead, it would be preferable to determine eligibility based on some expected attribute, secured by something we can externally verify like an RSA-signed JWT:
This is how Hardpoint governs access to private resources: use a known trust anchor instead of shared secrets or static network attributes.
Best of all, apart from specifying an entry rule(s), there's nothing else to configure: your Vercel project doesn't need any knowledge of Hardpoint or vice-versa.
Dead-ends
Second, we have the sovereignty conundrum: SaaS operators are realizing that running performant and cost-effective AI services at scale means tackling the whole playbook of classical distributed systems problems. In a nutshell, doing this at planet-scale simultaneously requires both proximity to users, but also privacy. They're somewhat adjacent but occasionally competing concerns.
In the old days it was simple: you have your n-tier web app, stick some in-memory caching in here and there, and maybe add a public CDN for good measure. Lumping all your tenants in the same boat is generally not something you second-guess when you're still worrying about product-market fit, but AI (and prompting in particular) has shortened the timeline for customers to ask "where are you storing my trade secrets/medical data/PII?".
The specter of sovereign compute is rapidly transforming from an esoteric problem for B/C-round growth companies chasing Fortune 500 logos to an architecture headache that can lose sales for any company, regardless of size.
Remember how all these managed service vendors are kind of cloud-agnostic but not really? That leaky abstraction isn't just a developer issue, it's not lost on customers, either. For various reasons: geopolitics, the proliferation of AI and a weariness of data breaches, it's commonplace to be asked what cloud provider(s) you're building on top of, and sometimes customers won't like the answer. They may be able to point to some regulatory reason why they can't accept vendor , or it may just be internal politics; the point is not to pick the right provider but to have the agility to drop data into whichever one they want.
This kind of arbitrary tenant partitioning can be expressed as rules which are evaluated at the request level in our routing mesh.
While we don't support freeform rules in the UI at this time, we're working on refining the concept and actively soliciting feedback from early users. If you'd like to get involved, ping us through one of the channels in the conclusion.
Beyond networking
The MVP focuses on immediate pain points: auth and network security. But that's a prerequisite to our next step which is building and operating databases themselves.
While you can run our agent on any infrastructure you choose and get true end-to-end post-quantum** security, we can host Postgres™ and Redis™-compatible databases that are:
auto-provisioned: no herding RDS instances: configure your rules and they automatically and securely hook into your Hardpoint network
auto-placed: we ensure tenant data ends up in the cloud provider + region it's supposed to
auto-compliant: we deal with key hygiene, SIEM integration and all the other things you get asked for in customer RFPs
cost-effective: a full database per tenant/zone without the unit economics of a full DB
Conclusion
We want to be the data platform of choice for SaaS operators who need to marry edge-native capabilities, while treating tenant isolation and data residency as first-class concepts.
More concretely, this means being able to say "yes" to requests like:
"Customer A wants separate databases + encryption keys and audit integration with their SIEM"
"Customer B wants all their data to live in Germany because of [reasons]"
"We need to handle Customers A, B and C without messing up our unit economics or having our ops team quit"
"All these customers still want our CDN in their isolation zone"
We believe that we're at a point in time where many technologies (edge computing, microVMs, WASM and agentic AI to name a few) are coalescing to make a data platform like this buildable, and that we're the best team to do it.
If any of this has piqued your interest, sign up for the alpha for free now!
Any questions or feedback are welcome either via X or through our own Discord.
* this varies widely and warrants a dedicated future blog post
** another expansive topic deserving of its own post