The website was operating as expected when we reviewed its ownership and hosting arrangements.
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, its contracted deliverables, domain and data remain separable from Valen Systems’ reusable platform. Document how each party can continue operating after that separation.
- 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. Include that inventory in the deployment review and assign an owner to resolve any unclear access or ownership.
We corrected the ownership and hosting arrangement before an account dispute or urgent migration required a separation.