About Glinr
Push code.
Get a URL.
That's it.
Glinr exists because deploying a backend shouldn't require a DevOps degree, a Kubernetes cluster, or a $500 monthly bill. It should be as simple as pushing code.
A note from the founder
I've been the developer who spent three hours fighting with Nginx configs before ever writing a line of business logic. I've also been the developer who got a $800 cloud bill because a test service sat idle for a month. Neither of those things should happen to you.
The deployment platforms we have today are either too expensive, too complex, or both. Railway is great — but it charges per minute, so idle services quietly drain your budget. The DIY path (EC2, VPS, Kubernetes) gives you control but demands expertise. The gap in the middle — simple, affordable, flat-priced — is where Glinr lives.
Glinr is a one-person project right now. That means shipping fast, being honest about what doesn't exist yet, and building in public. The agent is open source. The pricing is public. The infrastructure isn't hidden behind vague "cloud" branding.
If you're a developer who just wants to ship, welcome.
What we believe
Flat pricing is a feature
Per-minute billing punishes you for having a life outside your dashboard. Glinr charges a flat monthly rate — whether your service handles 10 requests or 10,000. No idle charges, no surprise bills, no math required.
Transparency over abstraction
Your code runs on Hetzner in Frankfurt or Azure in Virginia. We're not hiding the infrastructure behind a brand. You know where your data lives, what hardware it runs on, and who operates the data centre. That's how it should be.
Developer-first, always
Every decision gets filtered through: does this make life easier for the developer? Auto-detection of language and framework. Zero-config HTTPS. Git-push deployments. No yaml files unless you want them.
No lock-in
The Glinr agent is open source (Apache 2.0). Your deployments are standard Docker containers. If you ever want to leave, your workloads move with you. We'd rather earn your business every month than trap you in it.
Open source at the core
The Glinr agent — the piece of software that runs on every deployment server, manages containers, proxies traffic, and streams logs — is fully open source under the Apache 2.0 licence. Read the code, audit it, self-host it, contribute to it.
The agent is written in Go. It talks to Docker, configures Caddy for automatic TLS, streams logs and metrics back over WebSocket, and builds your code with Nixpacks. It's the same code running in production on Glinr Cloud.
The dashboard and API are proprietary — that's how Glinr stays funded as a sustainable business. But the thing that touches your code and your servers will always be open and inspectable.
Infrastructure, honestly
Glinr Cloud runs on Hetzner in Frankfurt (EU) and Azure in Virginia (US). Both are reliable, well-operated infrastructure providers. Hetzner in particular gives exceptional price-to-performance, which is part of how we keep the pricing flat.
We're upfront about this because we think you deserve to know where your workloads live. Data sovereignty matters. If you're in the EU and need EU hosting, pick the Frankfurt region. If you need latency close to the US East Coast, pick Virginia.
EU Region
Frankfurt, Germany
Powered by Hetzner
US Region
Virginia, USA
Powered by Azure
The AI-native future of deployment
Glinr ships an MCP (Model Context Protocol) Server — which means your AI coding assistant can deploy your code directly, without switching to a browser. Tell Cursor or Claude to deploy your app, and it happens. Check deployment status, read logs, roll back — all from the same tool you're already using to write code.
This isn't a gimmick. As more developers work with AI pair-programmers, the deployment step shouldn't require a context switch. MCP closes that gap. The MCP server is available on Scale plan and above.
# From your AI assistant
deploy ./my-api --env production
→ Building with Nixpacks...
→ Live at https://my-api.glinr.app
Glinr is in public beta. That means some things aren't finished yet, and your feedback genuinely shapes what gets built next. If you find something broken, open an issue. If you have an idea, email me directly.
Start deploying