Nothing was broken. The client hadn’t threatened to leave, the website was up, and the deployment was doing exactly what it had been built to do. That was what made the problem easy to miss.
Valen Systems serves some client websites through a small wrapper on the primary host and places heavier site files behind a content delivery layer. That split is useful for asset-heavy builds, larger search systems, and experiences that don’t fit cleanly into a simple host. During a deployment review, I found that reusable Valen Systems-built machinery was sitting behind infrastructure too closely attached to a client-controlled domain.
The client should control the brand, domain, data, and deliverables it paid for. Valen Systems should retain the reusable publishing system, templates, deployment logic, and platform infrastructure used across customers. The architecture had blurred those two categories.
A domain is part of the control surface
A custom hostname isn’t merely a label. It participates in routing, caching, certificate handling, and the path by which browsers reach stored objects. Cloudflare's R2 documentation describes custom domains as a way to expose bucket objects through a domain and apply Cloudflare features such as caching and access controls.
That doesn’t mean the person who owns a domain automatically owns the storage account or the copyright in every file served through it. It does mean domain ownership, account ownership, deployment access, and operational continuity need to be mapped deliberately. If one party can change DNS while another party controls the bucket, the separation plan must be understood before a relationship becomes difficult.
Legal ownership and practical control are different questions
Serving code through a client's domain doesn’t automatically transfer copyright. The contract still determines which rights were assigned, which technology is licensed, and which deliverables belong to each party. The U.S. Copyright Office explains that copyright ownership and ownership of a particular copy are distinct concepts.
But a contract doesn’t replace operational clarity. Architecture determines who can route a hostname, deploy a release, revoke a credential, copy public assets, or keep a service running before lawyers are involved. Good agreements and clean infrastructure should describe the same boundary.
Public assets are still public
Moving a JavaScript bundle or stylesheet to a company-controlled CDN isn’t secrecy. If a browser needs a file, a visitor can usually retrieve it. The parts that create durable advantage shouldn’t depend on hiding inside a public bundle.
Credentials, proprietary datasets, orchestration logic, internal prompts, scoring systems, customer records, and reusable deployment controls belong behind authenticated services. Public pages and assets should be treated as delivery artifacts, not private working storage.
The boundary Valen Systems now uses
The client-facing surface stays on the client's canonical domain. Reusable platform assets and release infrastructure stay under Valen Systems-controlled accounts and domains. A thin wrapper can load an approved release, while the canonical domain still returns complete crawlable HTML to visitors and search engines.
Client-specific content and contracted deliverables remain identifiable. Reusable publishing code, generalized templates, release tooling, and internal operating systems remain company infrastructure. If the client leaves, it receives what it owns without taking the factory. Valen Systems can remove its platform without holding the client's domain or data hostage.
- Inventory the domain, bucket, Worker, credentials, source repository, data, and release owner.
- Separate public client deliverables from reusable platform machinery.
- Keep canonical URLs on the client domain even when assets come from a provider-controlled CDN.
- Make client data exportable and platform components replaceable.
- Write the same boundary into the contract and the deployment architecture.
Why this matters before anything goes wrong
NIST's small-business guidance recommends knowing which systems and services exist, who administers them, and what business risk follows if access is lost. That sounds basic because it’s basic. It’s also exactly the kind of work that gets skipped when a small company is shipping quickly.
The mistake didn’t hurt Valen Systems. It created a failure mode that could have hurt Valen Systems later. Fixing it while everyone was cooperative was far cheaper than discovering it during an account dispute or a rushed migration.