Deploy OpenText Web CMS Content Into Containers, Without Adopting Kubernetes
The OpenDeploy Receiver is the piece that accepts content, images and static assets from your OpenText Web CMS (TeamSite) servers and transfers them to your customer facing web sites. OpenText gives you two ways to stand one up: run their full software installer on a server you then own and maintain, or adopt a Kubernetes cluster and a deployment machine to manage their container images. Their images are only built for the second route. The images expect its configuration to arrive from a Kubernetes ConfigMap and its logs to be scraped off a cluster-mounted volume. That is a large amount of platform to take on for one long-lived, single-replica service.
Klish Group packages the same OpenText installer into an image that configures itself from environment variables and streams every log line to stdout as JSON. It runs the same way on a laptop, on a Swarm node, or in a Cloud Platform like AWS ECS.
Why Teams Ask Us For This Image
No Orchestrator To Adopt
Two settings - the container hostname and the name of your OpenText Web CMS (TeamSite) server - and it starts. No ConfigMaps, no Helm chart, no cluster.
Roughly 20% Smaller
491 MB against the vendor's 611 MB on the same OpenDeploy release, in 7-8 image layers instead of 37-39.
Logs You Can Query
Every log line leaves the container as JSON on stdout, including the full per deployment details.
Patched On Every Build
A maintained enterprise Linux base that rolls forward, with an SBOM and a vulnerability scan produced for every image we publish.
Side by Side With the Vendor Image
Measured directly against registry.opentext.com/ts-opendeploy-runtime at matching OpenDeploy releases.
| OpenText runtime image | Klish Group receiver image | |
|---|---|---|
| Runtime platform | Built around a Kubernetes deployment - configuration expected from a ConfigMap | Docker, Docker Compose, Docker Swarm, AWS ECS |
| Configuration | Cluster-supplied config files | Environment variables, applied by the entrypoint at startup |
| Base OS | Alpine 3.22, plus a 127 MB hand-installed glibc tree | Rocky Linux 9, fully package-managed |
| Patching | Frozen trees; the bundled Java runtime dates from April 2024 and cannot be updated in place | Every build rolls the base forward and installs the current OpenJDK from the distribution |
| Image size | 611 MB (23.4.x) - 672 MB (25.4.0.0) | 491 MB (23.4.x) - 520 MB (25.4.0.0) |
| Image layers | 37-39 | 7-8 |
| Getting logs off the box | A GELF appender to Graylog, plus a fluentd DaemonSet scraping container stdout, where the server's own output is discarded, leaving a handful of shell banner lines | Every log event on stdout as one JSON object per line, collected by whatever log driver you already use |
| Per-deployment item detail | File-only, it never enters log4j2, so neither the GELF route nor a stdout scraper can reach it | Relayed onto the same JSON stream, tagged and de-duplicated |
| Deployment log retention | Never pruned; grows for the life of the receiver | Swept daily on a retention window you set |
Logging That Actually Leaves the Container
OpenDeploy's server process is started in a way that sends its standard output to /dev/null, so a console appender cannot reach your log driver no matter how it is configured. A stock receiver container emits six lines to docker logs while writing the rest to a file inside the container.
We customized the behavior so every log event is written as JSON and streamed from the container's main process, so docker logs, the ECS awslogs driver, or any other log driver collects it with no sidecar, no log agent and no shared volume. Each event is a single line on the wire:
{
"ts": "2026-08-13T17:49:09.849Z",
"level": "INFO",
"logger": "serverLog",
"logfile": "odrcvr01_odrcvr.log",
"group": "",
"thread": "ReThread-0",
"msg": "ENG: Rcvr got request to receive a deployment.",
"ex": ""
}Complete Deployment Log Data
Every file received, created and renamed in any deployment log are written by OpenDeploy's native engine and never pass through its logging framework at all. That is not a configuration gap: OpenText's own Kubernetes deployment routes deployment logging to Graylog through a GELF appender, and because a GELF appender is a log4j2 appender, it carries exactly the same subset and leaves the item-level lines in the file. Our solution puts all of them on the same JSON stream, tagged so you can filter.
Accurate Health checks
A load balancer TCP probe on the deploy port caused OpenDeploy to process it as an inbound deployment and logs seven lines ending in the same error text a genuinely rejected deployment produces. At a typical two-subnet probe rate that is around 8,600 phantom failed deployments logged per day, masking real failures. We health check a port that logs nothing for the same connection verification.
Nothing accumulates forever
OpenDeploy writes a new log and XML manifest for every leg of every deployment, names them after the deployment, and never removes any of them. Our image sweeps them on a retention window you choose.
Runs on Common Platforms
Docker & Compose
A ready-made docker-compose.yml with the license mounted as a secret, a health check, and a stop grace period sized for the drain window.
Docker Swarm
A stack file that references the license as an external swarm secret, so no key material sits in the repository, and publishes the deploy port in host mode to keep the sending server's real address visible.
AWS ECS & Fargate
Task definition and AWS CDK examples, the license pulled from Secrets Manager by ARN.
Starting our receiver image takes the container hostname and the name of the OpenText Web CMS (TeamSite) server that will send to it. The entrypoint writes OpenDeploy's allowed-hosts and allowed-directories configuration from that, so there is no configuration file to template and no placeholder left behind:
docker run \
--hostname odrcvr01.example.com \
-e TEAMSITE_SERVER=teamsite.example.com \
-p 20014:20014 \
-v runtime-data:/data \
registry.example.com/opendeploy-receiver:23.4.2.0Only the deploy port needs to be reachable. The image has no companion containers and no external dependencies.
Built for AWS, Not Merely Able To Run There
Several of the enhancements included in these images were found from AWS ECS testing.
Task stops that complete
The vendor's stop script spends its time on a waiting on task execution plus a thirty-second sleep, which can reach past the 120-second maximum ECS allows. Every task stop was killed rather than gracefully shutdown. We run the one step that does the work, poll until in-flight deployments have drained, and exit.
A liveness signal ECS can see
ECS ignores a health check baked into an image, so we document the command to place in the task definition - one that returns a genuine exit code rather than always succeeding, and returns in about a tenth of a second.
The license kept out of your templates
Supply it as an environment variable, an AWS Secrets Manager reference, or a Docker or Swarm secret. With Secrets Manager only the ARN reaches your task definition, CloudFormation template and git history, and it can be rotated without redeploying.
Supply Chain You Can Hand To Security
Every image we publish is scanned before it is pushed, and the evidence is produced as an artifact rather than as an assertion.
A CycloneDX SBOM per build
A complete component inventory generated from the finished image, archived with every build and tracked over time. Yours to feed into your own scanning and compliance tooling.
A vulnerability gate, not a vulnerability report
A critical finding in anything we control fails the build and the image is never pushed. A readable HTML scan report is published with every build.
Vendor findings shown, never hidden
Some findings live inside OpenText's own payload and no base image or Dockerfile can patch them - they are present in OpenText's image too, and only a new vendor installer resolves them. We list them separately in the report.
Rebuilt monthly
A scheduled build every month rolls the base packages forward, so a release you deployed a year ago can be refreshed against today's operating system patches without an OpenDeploy version upgrade.
Releases Available Today
One image per OpenDeploy release, each built from OpenText's own installer. The correct Java runtime for the release is selected during the build, so upgrading is a tag change rather than a rebuild of your platform.
| Version | Java runtime | OpenText package date |
|---|---|---|
| 23.4.1.0 | OpenJDK 11 | February 8, 2024 |
| 23.4.2.0 | OpenJDK 11 | February 27, 2025 |
| 24.4.0.0 | OpenJDK 21 | October 22, 2024 |
| 24.4.1.0 | OpenJDK 21 | May 14, 2025 |
| 24.4.2.0 | OpenJDK 21 | September 1, 2025 |
| 25.4.0.0 | OpenJDK 21 | December 5, 2025 |
| 25.4.1.0 | OpenJDK 21 | May 28, 2026 |
You supply the license. These images package OpenText's own installer, so a valid OpenDeploy license purchased from OpenText is required to run these. What we provide is the packaging, the platform integration and the operational work around it.
What You Get
The image
Pulled from our registry or built in your own pipeline from the repository, so the image your auditors review is the one you produced.
Deployment templates
Compose file, Swarm stack file, ECS task definition and AWS CDK snippets - each with the settings that matter already correct.
New release packaging
When OpenText ships a new OpenDeploy version, we validate and package it.
Platform help
We can stand the receiver up in your environment, wire the load balancer and log destinations correctly, and deploy the surrounding infrastructure as code.
Someone who knows this product
Klish Group has run OpenText Web CMS (TeamSite), OpenDeploy and LiveSite for enterprise customers for years.