Skip to main content

When to Use a PaaS vs. a Cloud Provider: Why We Chose Kuberns for nublabs.com

July 16, 2026·7 min read

A large part of what we do at Nub Labs is cloud setup and maintenance. We help clients architect systems on AWS, deploy containerized APIs on GCP, manage databases on DigitalOcean, and build pipelines on Azure. We have opinions about all of them - when to use each, what it costs at scale, and where the rough edges are.

So when it came time to host nublabs.com, we had every option available to us. We chose Kuberns, an AI-powered PaaS built by an Indian team.

This post explains the reasoning. Not because Kuberns is always the right answer - it is not - but because the decision illustrates something we tell clients regularly: choosing cloud infrastructure is not about picking the best platform in the abstract. It is about matching the tool to the actual requirements of the project.

The decision framework we use

When a client asks where to host something, the first questions are not about platforms. They are about control requirements.

Do you need fine-grained control over the runtime environment? Custom kernel parameters, specific CPU/memory configurations, non-standard networking, GPU access, compliance constraints that require data residency - these push you toward IaaS. AWS, GCP, Azure, and DigitalOcean give you the raw infrastructure and full control over what runs on it.

Do you have a dedicated DevOps function or are you willing to build one? Running on a cloud provider at scale means managing servers, configuring load balancers, writing deployment pipelines, handling SSL certificates, setting up monitoring, and rotating secrets. This is real engineering work. Teams that do not have this capacity - or do not want to build it - often get more value from a managed platform.

What is the blast radius of downtime? A revenue-generating production API with SLAs and real users hitting it is a different situation from a marketing site. Both deserve reliability, but the investment in infrastructure complexity should match the risk profile.

Pros

  • Full control over runtime, networking, and compliance
  • Best option for complex architectures: microservices, data pipelines, GPU workloads
  • Most mature ecosystems for monitoring, security, and tooling
  • No vendor abstraction layer between you and your infrastructure

Cons

  • Significant operational overhead: deployment pipelines, SSL, patching, backups
  • Requires DevOps expertise or a dedicated hire
  • Cost can spiral without active resource management
  • Slower time-to-deploy for straightforward applications

A PaaS like Kuberns sits on the other side of this trade-off. You give up control. You gain speed and simplicity.

Why nublabs.com did not need a cloud provider

nublabs.com is a Next.js marketing site. It has a contact form that sends email via Resend. It has no database, no user accounts, no payment processing, and no SLAs with external parties.

Running this on AWS would mean: an EC2 instance or ECS cluster, a load balancer, an ACM certificate, Route 53 configuration, a deployment pipeline in GitHub Actions or CodePipeline, CloudWatch for logs, and regular patching. That is several hours of setup and ongoing maintenance for a site that needs to do one thing: load fast and not go down.

That is not a sensible use of engineering time. The infrastructure complexity is disproportionate to the actual requirements.

What Kuberns actually handles

Kuberns is an AI-powered PaaS. You connect your GitHub repository, and it reads your code to determine the framework, sets the build and start commands, prompts you for environment variables it detects from your code, and deploys the application with HTTPS enabled.

For nublabs.com, the deployment flow was:

  1. Connect the GitHub repository
  2. Kuberns detected Next.js App Router, set next build and the correct start command
  3. We filled in four environment variables (API keys for Resend and PostHog)
  4. Custom domain pointed, DNS propagated, site was live

No Dockerfile. No pipeline configuration. No server to patch.

Since then, every push to main deploys automatically. We have not touched the hosting configuration once.

Kuberns supports Next.js, Node.js, Python (FastAPI, Django, Flask), Go, Ruby, and PHP. Framework detection is reliable for standard project structures.

Where we still recommend cloud providers

This is not a case for PaaS across the board. Most of the production systems we build for clients run on cloud providers, and for good reason.

  • Complex data architectures - when a client's system involves multiple databases, message queues, caching layers, and background workers, the composability of AWS or GCP is genuinely valuable
  • Compliance requirements - data residency, SOC 2, HIPAA, and similar frameworks often require specific infrastructure configurations that a PaaS abstracts away in ways you cannot audit
  • High-traffic production APIs - when you need horizontal scaling with precise control over concurrency, memory allocation, and response time, a cloud provider gives you levers a PaaS does not
  • Machine learning workloads - GPU instances, model serving infrastructure, and training pipelines live on cloud providers

The skill in cloud architecture is not knowing all the platforms. It is knowing which constraints matter for a given project and matching the platform to those constraints.

The honest trade-off

Choosing Kuberns over a cloud provider means accepting less control. You cannot configure the underlying server. You are dependent on Kuberns's infrastructure decisions. If they have an outage, your site is down and you cannot reroute traffic yourself.

For nublabs.com, those are acceptable risks. Our site going down for an hour is not a business-ending event. A competitor's similar site going down for an hour on AWS is also not a business-ending event - it just costs more to maintain.

For a client's production payment API, those risks are not acceptable. Different project, different answer.

What we learned that is actually useful

Match infrastructure complexity to actual requirements. The instinct among engineers is to over-engineer hosting. AWS is impressive and capable. That does not mean everything should run on it.

A PaaS is not a shortcut - it is a trade-off. You are trading control for speed. That is a legitimate trade-off for the right projects. Know what you are giving up.

The AI features in platforms like Kuberns are genuinely useful for the right scope. Framework detection and code-aware environment variable prompting are not gimmicks. For a standard application, they reduce the time-to-deploy meaningfully. For a custom or complex setup, they may not cover your case and you will be overriding them anyway.

If you are building something where these questions matter - choosing the right cloud setup for a production system, or deciding whether a PaaS makes sense for your architecture - that is the kind of problem we work on with clients. The answer is almost never the same twice.

nublabs.com is hosted on Kuberns. We have no commercial relationship with Kuberns.