Acceptable use policy

Scope, and who this binds

This policy (the "AUP") applies to every use of the network, systems, addresses and facilities of Andrii Co., a Washington for-profit corporation (UBI 604505773), doing business as Andrii Cloud ("we", "us", "Andrii Cloud"), including any colocation, transit, address assignment or managed service we provide, and to the use of andrii.cloud itself.

It is written now, before the first customer, because it is the policy we intend to enforce from the first day of service and because an upstream, an exchange or another operator's abuse desk is entitled to read it before then. No colocation service is being sold today, so as of the effective date above this policy binds the use of this website and nothing else; it becomes part of any service agreement we later sign, and it is incorporated into the draft at colocation terms.

Flow-down. If you resell, sublet, share or otherwise let another person use service we provide you, this policy applies to that person's use as well, and you are responsible for it as if it were your own. You must bind your own users to terms at least as strict as these, you must operate an abuse contact that answers, and you must be able to act on a report we forward you within the deadlines below. We deal with you; we do not chase your customers.

We may change this policy. A material change is published with a new version number across the whole legal set, and, once there is a customer to notify, with notice to that customer.

Zero tolerance: no notice, no cure period

The following are grounds for immediate suspension or termination without a cure period, and, where the law requires or permits it, for referral to law enforcement. They are not a list of things we dislike; they are the categories where a delay to allow a fix would itself be the harm.

• Child sexual abuse material, in any form, and any attempt to distribute, store, advertise or facilitate it. We act on this immediately, we preserve what the law requires us to preserve, and we report as the law requires.
• Phishing and credential theft — hosting, staging, proxying or fronting a page or service designed to capture another person's credentials or payment details, and any infrastructure supporting it.
• Malware and command-and-control — distributing malicious code, or operating a control channel, drop site, loader, exploit kit or logging endpoint for one.
• Botnets and stressers — operating, renting, or providing infrastructure to a botnet, a booter, a stresser or any other denial-of-service-for-hire service.
• Carding and fraud infrastructure — trafficking in stolen payment card data, account credentials or identity documents, and the checking, validation and marketplace services built around them.
• Hijacked announcements — originating or propagating a BGP announcement for address space you are not authorised to announce, whether by mistaken configuration you fail to correct or by design. See "BGP hygiene" below.

Nothing in the enforcement ladder below limits what we may do in these categories. We would rather lose a customer than be the reason one of these stayed up for another hour.

Spam and unsolicited messaging

You may not send, relay, facilitate or provide infrastructure for unsolicited bulk or commercial electronic messages, and you may not host a service whose purpose is to send them. This applies whether the messages leave our network, arrive from somewhere else and are processed here, or point at a site hosted here — the "spamvertised" destination is as much our problem as the sending relay.

If you send commercial email at all, you send it in compliance with the law that applies to it, which in the United States includes the CAN-SPAM Act, 15 U.S.C. § 7702 and 15 U.S.C. § 7704, and the Federal Trade Commission's rule at 16 C.F.R. Part 316. In practice, and regardless of jurisdiction, we expect:

• a real, working opt-out in every commercial message, honoured promptly and without requiring an account, a payment or a reason;
• headers and a subject line that do not mislead about the origin or the subject of the message;
• a valid physical postal address in the message; and
• a list you can account for — consent you can show, and no purchased, scraped or "appended" addresses.

Outbound port 25. Outbound TCP port 25 is filtered by default on every assignment. We will open it for a customer that asks and can describe its mail operation, and we may re-close it on a complaint. This is not a judgement about you; it is the single cheapest control against a compromised host in a rack, and it is what lets us keep our address space deliverable for everyone in it.

If you run mail, run it properly. Forward and reverse DNS that match, an SPF record that reflects what actually sends, DKIM signing, and a DMARC record with a working reporting address. We will set the reverse DNS you ask for on addresses we assign you, and we will not set one that impersonates a domain you do not control.

Network abuse, and source-address validation

You may not use our network to attack, overload, degrade or gain unauthorised access to any system, whether ours, another customer's or a third party's. That includes port scanning and vulnerability probing of hosts you do not control or have not been authorised in writing to test; denial-of-service traffic of any volume; brute-force authentication attempts; and traffic designed to evade another operator's filtering.

Source-address validation is required. Every packet leaving your equipment must carry a source address that belongs to you and is routed to you — BCP 38 / RFC 2827 ingress filtering, applied at your edge. We filter at ours as well, and a persistent spoofing source is filtered or suspended rather than debugged indefinitely. Spoofing is the precondition for most reflection attacks, and an operator that permits it is a participant in them.

We scan our own address space. We routinely scan the addresses we assign for the services that make reflection and amplification attacks possible — open DNS resolvers, NTP servers answering monlist, open SNMP, exposed memcached, and SSDP and CLDAP responders among them. We are looking at our own space, not at yours elsewhere, and we are looking for a configuration, not at your data. When we find one we will tell you and ask you to fix it; if it is already being abused, or if it is not fixed, we will filter the port or suspend the assignment first and continue the conversation after.

Denial-of-service mitigation is not a credit event. When traffic to an address threatens the stability of our network or our upstreams', we may filter it, rate-limit it, or announce it to a remotely-triggered blackhole — which makes that address unreachable, which is the point. We will tell you when we do it and why. Mitigation, including blackholing, is excluded from any service level commitment we may later make.

BGP hygiene, addresses and announcements

If you announce address space from our network, or if we announce space on your behalf:

• Announce only what is yours. You must hold the space, or hold a current written authorisation from the holder. A hijack — announcing space you are not authorised to announce — is a zero-tolerance category above, and we will withdraw the session first and discuss it afterwards.
• Publish your intent. Address space you announce must be covered by RPKI route origin authorisations and by matching route objects in an internet routing registry, before the session comes up. We drop RPKI-invalid routes, and we build prefix filters from registry data; an announcement that does not match what you have published will not propagate, and that is working as intended.
• Keep your contacts current. The abuse and technical contacts for your space must reach a human who can act. This is not administrative tidiness — it is the difference between a filter and a suspension when something of yours is compromised at three in the morning.
• Do not leak. Do not re-announce our transit to another transit provider, do not de-aggregate beyond what is operationally necessary, and apply outbound filters that make a leak impossible rather than unlikely.
• Addresses we assign are licensed, not sold. Address space we assign you remains ours, is assigned for the duration of your service, and returns to us when the service ends. You may not sell, lease, transfer or sublet it, and you may not announce it after service ends.

Power, cooling and mining

Two rules govern what you may run in a rack, and neither of them is about what your workload is for.

Power is a contracted quantity, and it is continuous. Your equipment must stay within the power committed in your service order, measured as continuous draw, with the circuit's usable capacity taken as the derated figure the electrical code requires rather than the breaker's nameplate rating. Exceeding it is not a billing question in the first instance; it is a risk to every other customer on that circuit.

Heat is the other half of the same rule. Equipment whose thermal output exceeds what the space can remove from the position it occupies may be required to move, to be throttled, or to be powered down, whatever it is doing.

Cryptocurrency mining and other sustained full-load workloads are treated under those two rules and no others. We have no objection in principle to a lawful workload that runs a machine at capacity; we object to an unmetered one. So: sustained full-load compute requires written approval in advance and a dedicated metered circuit, and without both we will treat it as an over-draw. If you intend to run one, tell us before you rack it and we will say yes or no on the basis of power and cooling.

Copyright, and repeat infringers

We are not the publisher of anything on colocated equipment and we do not monitor it. When we receive a complete notice of claimed copyright infringement we act on it under the process described at abuse and DMCA, which is also where the designated agent, the notice elements, counter-notification and our address for service are published.

We terminate repeat infringers. As 17 U.S.C. § 512(i) requires of a service provider that wishes to rely on the safe harbours, we have adopted and we reasonably implement a policy providing for the termination, in appropriate circumstances, of the service of subscribers who are repeat infringers. What counts as "repeat" and "appropriate" is a judgement we make on the facts, and a counter-notification that stands unanswered does not count against you.

What we deliberately do not do

Being explicit about what we do not monitor is part of the policy, because a vague promise to police everything is both false and worse for you than a narrow one we keep.

• We do not inspect the content of your traffic, and we do not run deep packet inspection on customer traffic as a matter of course. What we look at is flow-level and volumetric: what is going where, how much, and whether it is hurting somebody.
• We do not log in to colocated equipment. We have no credentials on your machines and we do not want any, except under a managed-services schedule you have signed, for the systems that schedule names.
• We do not review what you host before or after you host it, and we do not act as an arbiter of lawful speech. We act on the categories in this policy, on a valid legal process, and on a complete infringement notice.
• We do not promise to notice. Nothing here is a commitment to detect a breach of this policy. Our not having noticed is not permission, and is not a waiver.

How we enforce: the ladder and its deadlines

Our first preference is that you fix it. The ladder below is what happens when that is in doubt, and we climb it only as far as we have to. The zero-tolerance categories start at the top.

• 1. We forward the report, with a deadline. You get the complaint, what we can verify, and the time you have to respond. The standard deadline is 24 hours. For an attack in progress it is 4 hours, at any hour of any day, which is why your abuse contact has to be one that answers.
• 2. We filter or null-route. Where the harm is ongoing and narrow, we filter the port, rate-limit the flow, or blackhole the address. This is a containment step, not a penalty, and we reverse it when the cause is fixed.
• 3. We suspend the service. The affected service stops. Your equipment stays where it is and stays yours; your announcements are withdrawn.
• 4. We suspend the account. Every service, where the problem is not confined to one.
• 5. We terminate. The agreement ends under its own terms, and you retrieve your equipment under those terms.
• 6. We refer. Where the law requires a report we make it; where it permits one and the conduct warrants it, we may make it. Referral is not a substitute for any of the steps above and does not wait on them.

We may skip steps. A live attack, a hijack, or any zero-tolerance category is contained immediately and discussed afterwards. We will always tell you what we did and why, unless a law forbids it — see the legal-process section of abuse and DMCA, where the default is that we tell the affected customer.

Reinstatement follows a fix we can verify and an explanation of how it will not recur. A second occurrence of the same cause is not treated as a first one.

How to report a problem

Send abuse reports to abuse@andrii.cloud. That is the address published in the ARIN Whois record and the PeeringDB entry for AS402801, and it is the one to use if you found us by looking up an address rather than by visiting this site.

A report we can act on contains: the source and destination addresses, timestamps with an explicit time zone, the protocol and ports, and a few lines of raw evidence — log entries, headers with full received lines, or a packet capture excerpt. Please send text rather than screenshots, and please do not send us malware samples as live attachments.

We aim to acknowledge a report within one business day, and faster for an attack in progress. We will tell you that we received it and that we acted; we will not tell you who the customer is, and we will not forward your report to them with your address stripped out unless you ask us to strip it.

Copyright notices, counter-notifications, subpoenas, court orders, preservation requests and other legal process go to the addresses at abuse and DMCA, not to this one — abuse@andrii.cloud is an operational mailbox and is not an address for service of process.

Andrii Co., a Washington for-profit corporation (UBI 604505773), doing business as Andrii Cloud
11826 NE 167th St, Bothell WA 98011-5456
United States

Version 2026.09.18 · Effective 18 September 2026