Ship

Your team can just ship things.

A push-to-deploy PaaS for vibe-coded internal apps and PR previews.
Your compute, your auth, a platform you don’t have to run.

1

Install Ship anywhere you deploy.

Machines join a shared compute pool you set up once with one command or your favorite IaC tooling. The daemon connects to Ship to receive workloads, deploy apps to the pool, and route inbound connections.

CLI
Kubernetes
Terraform
Argo CD
Flux
OAuth

Installing the Ship daemon to connect a machine to Ship's cloud

2

Connect your repo.

Ship detects your stack, builds your app's container, and deploys it across your compute. No Dockerfile required.

Connecting a git repository to Ship to build and deploy its container

3

Share your app. Control access.

Every app gets a URL that can be public to the world or private to your team.

An app URL that can be public to the world or private to a team

4

Push to deploy on your compute.

On every git push, Ship deploys your apps and spreads replicas across your compute pools by default. One provider's outage won't take your apps down.

Ship spreading app replicas across compute pools from multiple providers on git push

Why Ship

DevEx. Velocity. Control.

Everyone builds apps now. Let them ship quickly on compute you govern instead of your infra sprawling onto a PaaS.

Get push to deploy and PR previews

Your team wants the ergonomics of PaaS, you want infrastructure you control. Now everyone wins.

Know where everything runs

Every app lands in one place you can see, instead of on a personal VPS you find out about later.

You're not limited to PaaS primitives

Your team's apps can use S3, RDS, IAM roles—anything in your providers' catalogs.

Choose the best compute providers

Optimize for price, geography, GPU, or cross-provider redundancy without changing your deploy workflows.

Don't panic over every PaaS security incident

Breaches seem to happen with alarming frequency these days, don't they?

Operate one platform, not many

Keep using the observability and security tools you already standardized.

“A self-hosted PaaS in your VPC!”

We’ve heard that story before.
Ship is different.

You don’t host the control plane. Yes, your coding agent writes great Terraform, but with Ship, you only install a lightweight daemon and operationalize nothing. Nothing messes with your existing infra.

The gateway is built in. The agent connects your apps with secure tunnels and gives them URLs. Receive requests on any hardware without reconfiguring your network.

What will your team ship first?

No matter the app, public or private: one workflow covers the deployment, the URL, the access, and the routing.

https://mcp-server.acme.com
https://dashboard-pr-42-preview.internal
https://discord-bot.ngrok.app
https://n8n.internal
https://fastapi.acme.com
https://excalidraw.internal
https://vibe-coded-dashboard.ngrok.app
https://atlantis.acme.com
https://lunch-roulette.internal

https://nextjs-app.acme.com
https://slack-bot.ngrok.app
https://grafana.internal
https://docusaurus.acme.com
https://streamlit.ngrok.app
https://kafka-ui.internal
https://strapi.acme.com
https://go-api-rust-rewrite.internal
https://anything-with-a-dockerfile.ngrok.app

Works anywhere

New deployment targets just dropped.

Bring the compute you already run with Terraform, Argo CD, or Flux, or connect a provider and let Ship provision pools of VMs, GPUs, or Kubernetes clusters for you. Either way, apps land in shared pools your platform team owns, not one-off clusters people spin up and forget.

Ship provisioning VM pools, GPUs, and Kubernetes clusters across providers

Authentication

Auth the app author can't skip.

Set SSO, OAuth, OIDC, or IP restrictions at the platform level, and Ship enforces them in front of every app. Nobody has to remember auth, and no internal app sits on an open URL.

Access rules with OAuth, OIDC, and IP restrictions enforced in front of an app

CI preview

Preview environments the whole internet can't see.

Every pull request gets a preview with a .internal URL that's only available on your team's private network.

A pull request preview environment on a private .internal URL

Gateway

With a production-grade gateway built in.

Flip on auth, firewalls, bot-blocking from a single screen. Ship turns those choices into Traffic Policy and enforces them at ngrok's cloud, before requests reach your app. DDoS protection and global acceleration come standard.

Ship's Gateway configuration panel with controls for acceleration, authentication, bots and crawlers, DDoS protection, and firewall

Service-to-serviceComing soon

Services find each other by URL.

An app on a VM can call an API in your K8s cluster, no matter the networks or continents between them.

An app on a VM calling an API in a Kubernetes cluster by URL

Pricing

$0.001

per workload-hourplus Gateway traffic costs

See full pricing

Already have a gateway? Pay only for workload hours.

All the boxes you need to check to safely host apps from the vibe-coding masses.

Security Trust Center

SOC 2 Type II

Outbound-only daemon

HIPAA & BAA

Code stays on your compute

GDPR

SSO in front of every app

RBAC

Scoped, revocable credentials

Audit logs

WAF & DDoS protection

Frequently asked questions

One lightweight daemon per machine. It opens a single outbound connection to Ship's control plane, so there are no inbound ports to open or firewall rules to change. The daemon pulls the workloads for that host, builds your app's container, runs it, and reports status over that connection. It only talks outbound to ngrok cloud.

Yep. Ship installs next to what you run, without touching your setup. Point it at a VM, a bare-metal box, or a node in an existing Kubernetes cluster, or roll the daemon out with Terraform, Argo CD, or Flux. There's no native provider integration to wait for: if the daemon runs there, Ship deploys there. Your current workloads, schedulers, and networking keep running as they did.

Once: connect a provider or point the daemon at machines you already run, define the compute pools, and set the access rules every app inherits. After that, an app author connects a repo and pushes. Ship builds the container, deploys it to the pool, and puts the platform's auth in front of the URL. The infra team never becomes the deploy bottleneck, and app authors never need to touch the infrastructure.

It does, and day one was never the hard part. Your agent can scaffold a cluster, wire up ingress, and write the pipelines, but everything it creates becomes a platform you operate: upgrades, certificate rotation, secrets, on-call. Ship splits that differently. Use your agent and your IaC to install the daemon and configure your pools, then ngrok runs the control plane, the gateway, and the auth in front of every app. You keep the automation and drop the maintenance.

Nope. Your apps run on your machines, so deployed replicas keep serving traffic even when the control plane is unreachable. An outage pauses control-plane work like new deploys, config changes, and scheduling. It doesn't stop the apps already running.

When you connect a cloud provider, Ship gets scoped credentials to provision and manage only the compute you point it at. Your application traffic flows through the built-in gateway so it can route, authenticate, and protect requests, and you control what gets logged. Because the daemon only makes outbound connections to deploy targets you've granted, a compromise can't reach past them, and you can revoke a host or a provider connection whenever you want.

At the built-in gateway, which authenticates and routes each request before it reaches your app. Traffic between the gateway and your daemon travels through an encrypted tunnel.

Ship keeps deploy history and event metadata. Request payloads aren't stored by default, and you control what the gateway logs and for how long.

Every deploy, config change, and access-rule change, along with who made it and when. Review the log in the dashboard or pull it from the API.

A workload is one running instance of your app, billed by the hour it's live and prorated to the second. Run three replicas and you pay three workload-hours per hour. Scale to zero and you pay nothing. Builds and stopped preview environments don't count.

Workload-hours cover the compute Ship runs for you. The requests served through your apps' URLs bill on ngrok's standard Gateway pricing. If you already pay for an ngrok gateway, Ship only adds workload-hours on top of what you have.

Everything that matters comes with you. Your apps are standard OCI containers built from your own repos and running on compute you own, so there's no proprietary runtime to unwind. Your deploy config lives in your repo and your provider accounts stay yours. Turn Ship off and you keep the machines, the images, and the configuration.

Your team can just ship things.

Install Ship anywhere you deploy.

Connect your repo.

Share your app. Control access.

Push to deploy on your compute.

DevEx. Velocity. Control.

Get push to deploy and PR previews

Know where everything runs

You're not limited to PaaS primitives

Choose the best compute providers

Don't panic over every PaaS security incident

Operate one platform, not many

“A self-hosted PaaS in your VPC!”

What will your team ship first?

New deployment targets just dropped.

Auth the app author can't skip.

Preview environments the whole internet can't see.

With a production-grade gateway built in.

Services find each other by URL.

All the boxes you need to check to safely host apps from the vibe-coding masses.

Frequently asked questions

What does the Ship daemon actually run on my host?

Can I run Ship alongside my existing infrastructure?

What does the infra team set up once, and what do app authors do every time?

My coding agent already writes Terraform and Helm. Why do I need Ship?

If ngrok's control plane has an outage, does my running app go down?

What can ngrok access, and where's the trust boundary?

Where does TLS terminate?

What does ngrok retain, and for how long?

What shows up in the audit log?

What counts as a "workload-hour"?

How does workload pricing combine with Gateway pricing?

What's portable if I leave Ship?

We already ship with Ship.
Now try it yourself.

Your team can just ship things.

How Ship works

Install Ship anywhere you deploy.

Connect your repo.

Share your app. Control access.

Push to deploy on your compute.

DevEx. Velocity. Control.

Get push to deploy and PR previews

Know where everything runs

You're not limited to PaaS primitives

Choose the best compute providers

Don't panic over every PaaS security incident

Operate one platform, not many

“A self-hosted PaaS in your VPC!”

What will your team ship first?

New deployment targets just dropped.

Auth the app author can't skip.

Preview environments the whole internet can't see.

With a production-grade gateway built in.

Services find each other by URL.

All the boxes you need to check to safely host apps from the vibe-coding masses.

Frequently asked questions

What does the Ship daemon actually run on my host?

Can I run Ship alongside my existing infrastructure?

What does the infra team set up once, and what do app authors do every time?

My coding agent already writes Terraform and Helm. Why do I need Ship?

If ngrok's control plane has an outage, does my running app go down?

What can ngrok access, and where's the trust boundary?

Where does TLS terminate?

What does ngrok retain, and for how long?

What shows up in the audit log?

What counts as a "workload-hour"?

How does workload pricing combine with Gateway pricing?

What's portable if I leave Ship?

We already ship with Ship.Now try it yourself.

We already ship with Ship.
Now try it yourself.