DMCA Takedowns Land on the Platform, Not the Tenant: The Notice-and-Takedown Runbook a Self-Hosted PaaS Needs Before the First Complaint

In November 2025, researchers at CyberArmor documented at least 28 distinct phishing campaigns serving fake login pages and remote-access malware from *.vercel.app subdomains, targeting more than 1,271 users. The abuse reports didn't go to whoever clicked "deploy" on the phishing kit. They went to Vercel. That is the deal every multi-tenant platform signs, usually without reading it: the moment tenants serve content from your domains, infringement and abuse notices arrive at your abuse contact, not theirs — and your legal protection depends on machinery that existed before the notice arrived.

If you run a self-hosted PaaS on machines you own, nobody hands you this machinery. A designated DMCA agent, a repeat-infringer policy, per-tenant suspension mechanics, evidence handling, counter-notice workflows: none of it ships with your ingress controller. And unlike your uptime or your build times, you don't get to iterate on it after the first incident. Safe-harbor protection in both the US and the EU turns on whether the process existed and was followed when the notice landed. So here is the runbook, up front, before the first complaint.

The runbook, up front​

Everything below fits in two artifacts. Build the first one this week; rehearse the second one before you need it.

Artifact 1: pre-notice machinery (must exist before any notice arrives)

Artifact 2: per-notice workflow (DMCA vs DSA side by side)

The rest of this post unpacks both artifacts: why multi-tenant platforms owe them, what each jurisdiction concretely requires, and how the mechanics work on a Kubernetes-based PaaS.

Why multi-tenant changes everything​

If you self-host a single app with Coolify or Dokploy on one box, you will likely never see a takedown notice. You are the tenant. There is no abuse contact but you, no shared domain reputation to protect, no stranger's content served from your hostname. Notice-and-takedown is a problem multi-tenancy creates, and it arrives with the second tenant.

Three things change the day strangers deploy on your platform. First, you own the domain under fire: phishing kits and pirated streams served from *.onbex.co-style subdomains get the platform's hostnames reported to blocklists, Safe Browsing, and brand-protection vendors. Interisle's 2025 phishing report singled out rising abuse of webflow.io and vercel.app subdomains, and Trend Micro telemetry counted dozens of live phishing sites on vercel.app and lovable.app alone. One tenant's phishing page can stain a domain every other tenant shares.

Second, you own the ingress the notice names. A DMCA notice identifies infringing material by URL. The host serving that URL — your ingress, your IP space, your abuse contact in WHOIS and security.txt — is the service provider the statute talks to. Your tenant is a legal stranger to the complainant.

Third, your protection is procedural, not moral. Neither US nor EU law asks whether you meant well. Both ask whether you had the machinery and followed it: designated agent, repeat-infringer policy, expeditious action, proper notifications. A platform that takes down the wrong thing slowly with no records is worse off than one that takes down the right thing fast with receipts.

What US law requires: DMCA §512(c) in one page​

(The usual caveat: this is an operator's summary, not legal advice. Have counsel review your policy.)

A PaaS that stores tenant content at a tenant's direction is a §512(c) "hosting" service provider. The safe harbor has threshold requirements that must hold continuously, plus per-notice duties:

• Designated agent. Name an agent with the Copyright Office through its online system, keep the registration current (renewals every three years), and post the same contact info conspicuously on your site. A stale agent entry is one of the cheapest ways to lose the harbor.
• Repeat-infringer policy. Adopt, tell subscribers about, and reasonably implement a policy for terminating repeat infringers in appropriate circumstances. "Reasonably implement" is where platforms die: Cox Communications lost its safe harbor because its repeat-infringer process was, in the courts' view, theater — and that loss is what let the billion-dollar Sony/BMG litigation reach a jury at all.
• Expeditious takedown. On a valid notice — identified work, infringing location, complainant contact, good-faith statement, signature — remove or disable access fast. The statute doesn't name hours, but courts read "expeditious" against your capabilities: an automated platform that sits on a valid notice for a week has a harder story than a two-person shop.
• No red-flag blindness. If infringement is blatantly obvious to a reasonable person (the proverbial pirated-movies-4k tenant), you can't hide behind "nobody sent a notice." You don't have to go hunting — there is no general monitoring duty — but you can't ignore the obvious.
• Counter-notice and put-back. When you remove content, tell the tenant and explain the counter-notice right. A valid counter-notice (identification, consent to jurisdiction, good-faith statement) obliges you to notify the complainant and restore the material in 10–14 business days unless the complainant files suit. Miss the clock and you trade one liability for another.

One 2026 development operators should read carefully rather than celebrate: in March 2026, the Supreme Court unanimously tossed the $1 billion verdict against Cox in Cox v. Sony, holding that an ISP is not contributorily liable for subscribers' piracy merely by providing internet service.

That narrows secondary liability for mere-conduit ISPs — but it does not touch §512(c)'s notice-and-takedown duties for hosts. Your PaaS stores and serves the bytes. The expeditious-removal obligation, the agent, and the repeat-infringer policy all still apply in full. If anything, the decision sharpens the line: conduits got relief precisely because they don't host anything, which is the opposite of your architecture.

Scale note for the skeptical: GitHub's 2025 transparency report logged record DMCA takedown volume. Notice-and-takedown is not a corner case that happens to other platforms; at any real tenant count, it is a standing operational load with a legal clock attached.

What EU law requires: the DSA treats your PaaS as a hosting service​

Since the Digital Services Act became fully applicable in February 2024, EU law sorts intermediaries into tiers — and a PaaS that stores tenant apps and content is a hosting service even if it is nowhere near "platform" scale. The hosting tier carries duties that apply from day one, to small hosts as much as large ones:

• Notice-and-action mechanisms. Anyone — not just rightsholders — must be able to submit illegality notices electronically. "Illegality" here is broader than copyright: phishing, fraud, counterfeit goods, hate speech, and more all qualify.
• Statement of reasons. Every restriction decision (removal, suspension, demotion) needs a clear explanation to the affected user, covering the facts, the legal or contractual basis, and redress options — and these statements feed the Commission's public transparency database. Your per-notice template is a compliance artifact, not a courtesy email.
• Expeditious action on knowledge. Like the DMCA, the DSA's hosting liability exemption survives only if you act expeditiously once you have actual knowledge of illegality. A substantiated notice is actual knowledge.
• No general monitoring duty. You are not required to scan all tenant content proactively — but as with red-flag knowledge under the DMCA, willful blindness to the obvious is not a strategy.
• Transparency reporting. Yearly public reports on notices received and actions taken. Start counting from the first notice; reconstructing a year of abuse handling from chat logs is nobody's idea of fun.

The DSA's teeth are no longer theoretical. In December 2025, the Commission fined X €120 million in the first DSA non-compliance decision; in May 2026, Temu drew €200 million — the highest DSA fine to date — for systemic-risk failures, with fines able to reach 6% of global turnover and a Shein investigation opened in February 2026. A small PaaS won't draw Temu-scale fines, but the enforcement pattern matters: the Commission is working through investigations methodically, and national Digital Services Coordinators handle the long tail of smaller services. "Too small to matter" is a grace period, not an exemption.

Note the asymmetry in the per-notice table above: the DSA has no DMCA-style 10–14-day put-back clock. Instead, it requires accessible internal complaint-handling and, for larger services, out-of-court dispute options. Your runbook needs both tracks: the DMCA's rigid clock for US copyright notices, and the DSA's reasoned-decision-plus-redress track for EU illegality notices — which will sometimes be the same notice wearing two hats.

The mechanics: one tenant dark, everyone else lit​

Law sets the what; your platform sets the how. On a Kubernetes-based PaaS, the takedown primitive should be a per-tenant routing decision, not an infrastructure event:

• Suspend the route, not the ingress. Disabling one tenant's hostname — flipping its Ingress/HTTPRoute to a block page or scaling its workloads to zero behind a suspension marker — must be a single action that cannot typo its way into touching shared ingress, other tenants' routes, or the control plane. Test it in staging the way you'd test a backup: the first live takedown, under a legal clock, is a terrible time to discover your suspension script takes the whole gateway with it.
• Snapshot before you remove. Copy the accused content (container image digest, rendered pages, deploy metadata, timestamps) to immutable evidence storage before removal. Counter-notices, DSA appeals, and law-enforcement referrals each need to examine what you took down; "we deleted it" is an answer that satisfies nobody.
• Track strikes per tenant, across notices. Your repeat-infringer policy is only "reasonably implemented" if strikes accumulate against accounts and something happens at the threshold — suspension, then termination. Log every notice, action, timestamp, and notification. This log is simultaneously your DSA transparency source, your DMCA implementation evidence, and your defense exhibit.
• Handle counter-notices like the clock they are. DMCA counter-notices start a 10–14 business-day fuse ending in restoration or a lawsuit; DSA internal complaints need reasoned, timely responses. Route both to a human with a calendar, not a queue nobody owns. A valid counter-notice you ignore converts your good-faith takedown into the tenant's grievance.
• Escalate by category, not just by volume. Copyright notices follow the DMCA track; phishing and fraud get the fastest lane you have (blocklist delisting takes far longer than listing, so hours matter); CSAM and imminent-harm content bypass the standard workflow entirely — remove immediately, preserve evidence, report to the relevant authority (NCMEC in the US; law enforcement under DSA duties in the EU). Three different clocks, three different playbooks, one intake.
• Protect the shared domain as its own asset. Per-tenant subdomains contain blast radius; a platform that serves every tenant from one apex hostname shares one reputation fate. Monitor Safe Browsing and major blocklists for your domains, register with brand-protection and anti-phishing feeds, and be willing to suspend first and investigate second when a tenant is actively burning the domain every other tenant lives on.

Single-box tools never needed any of this because they never created the relationship: no strangers, no shared domain, no abuse contact but the owner. The day your platform hosts someone you don't know, you inherit the obligations of everyone who did it before you — Vercel's abuse queue, GitHub's transparency report, your national coordinator's inbox.

The only choice is whether the machinery exists before the first notice or gets built during it, under a clock, with a complainant's counsel watching.

Build the checklist this week. Rehearse the takedown in staging. Log everything. The notice is coming; the runbook decides whether it's a Tuesday or a crisis.

Running your platform on machines you own shouldn't mean facing abuse handling alone — bex.co is the open-source, AI-native Render alternative: push a git repo, get a running HTTPS service on your own infrastructure, with the tenant isolation and per-app controls a real takedown runbook needs. Star the repo on GitHub or deploy your first app today.