Selling self-hosted software to enterprises is a lucrative nightmare; here is how to manage the deployment chaos without becoming their unpaid sysadmin.

The Enterprise “On-Prem” Trap: Delivering Self-Hosted SaaS Without Losing Your Soul

I still wake up in a cold sweat thinking about the “FinCorp” deployment of 2019. We had just closed our biggest contract to date—an enterprise license that would effectively double our ARR. The catch? They refused our AWS cloud. They wanted it running on their metal, behind a firewall that made North Korea look like an open network.

I spent three weeks on a Zoom call with a guy named Greg who refused to give me SSH access to prod-db-01. I was trying to debug a race condition in our Redis cluster by asking Greg to cat log files and read them out loud to me. That is not DevOps; that is torture. If you are reading this, you are probably staring down the barrel of a similar contract. You built a SaaS, but they want a downloadable binary. Let’s talk about how to survive this.

The “Why”: It’s Not About Logic, It’s About Liability

Why do they do this? Why would a company pay premium pricing just to endure the headache of managing the infrastructure themselves?

In my experience at TechResolve, it usually boils down to three things:

• Data Sovereignty: Legal says the data cannot leave their physical building (or their specific AWS VPC).
• Compliance Theater: Their SOC2 or HIPAA auditor is terrified of multi-tenant architectures.
• Legacy inertia: They have a sunk cost in a massive VMware farm and, by god, they are going to use it.

You cannot argue them out of this. You have to engineer around it.

Solution 1: The “Simple” Fix (Docker Compose + Bash)

If your stack is relatively lightweight, do not overcomplicate it with Kubernetes right out of the gate. The easiest way to ship to an enterprise with a skeptical IT team is a zipped tarball containing a Docker Compose file and a heavily commented shell script.

We call this the “Ikea Approach.” You give them the parts and the instructions, and you pray they don’t assemble it upside down.

#!/bin/bash
# install.sh - The "Please don't break this" script

echo "Starting TechResolve Enterprise setup..."

# Check if Docker is actually running because Greg usually forgets
if ! docker info > /dev/null 2>&1; then
  echo "Error: Docker is not running. Please start the daemon."
  exit 1
fi

# Load the images from the offline tarball (Air-gap friendly)
echo "Loading docker images..."
docker load < techresolve-v2.4.0.tar.gz

# Spin it up
docker-compose -f docker-compose.prod.yml up -d

echo "Deployment complete. Please point your reverse proxy to port 8080."

Pro Tip: Never rely on their internet connection to pull images. Enterprises love air-gapped networks. Always ship a "fat" tarball with `docker save` images included.

Solution 2: The "Professional" Fix (Replicated / KOTS)

Eventually, `docker-compose` falls apart. You need scaling, you need rolling updates, and you need to stop debugging their Linux kernel versions. This is where you look at tools like Replicated or the Kubernetes Off-The-Shelf (KOTS) model.

Essentially, you package your Helm charts, and these platforms wrap a nice UI around it for the customer. It gives them a button to click for "Update" so they stop calling you.

Solution 3: The "Nuclear" Option (The Virtual Appliance)

Sometimes, the client's environment is so hostile—think Red Hat 6, custom kernels, or weird security agents that kill your processes—that you just can't run your binary on their OS.

In these cases, I go Nuclear: The OVA (Open Virtual Appliance).

You pack the entire Operating System, configured exactly how you like it (I prefer a hardened Ubuntu LTS), along with your app, into a single VM image. You tell the client: "Import this file into vSphere. Turn it on. Do not touch the inside."

# Packer snippet for building the appliance
packer {
  required_plugins {
    vsphere = {
      version = ">= 1.0.0"
      source  = "github.com/hashicorp/vsphere"
    }
  }
}

source "vsphere-iso" "techresolve-appliance" {
  vm_name       = "TechResolve-Ent-v2.4"
  CPUs          = 4
  RAM           = 16384
  # The secret sauce: Locking them out
  ssh_username  = "admin"
  ssh_password  = "ChangeMeImmediately!"
}

Is this hacky? Maybe. Does it prevent `sysadmin_dave` from editing your Nginx config and blaming you for the downtime? Absolutely. Sometimes, total isolation is the only way to guarantee stability.

Darian Vance

Lead Cloud Architect & DevOps Strategist

With over 12 years in system architecture and automation, Darian specializes in simplifying complex cloud infrastructures. An advocate for open-source solutions, he founded TechResolve to provide engineers with actionable, battle-tested troubleshooting guides and robust software alternatives.

🤖 Frequently Asked Questions