Skip to content
legal documents

Legal.

Four documents that govern the operating relationship between us and customers. Written in plain English by the same engineers who run the service, not by external counsel optimising for ambiguity. Last updated March 2026.

our approach to legal

Plain English, real commitments, no escape clauses.

Most hosting providers operate legal documents that read like insurance contracts: paragraphs of nested defined terms designed to maximise the provider's discretion and minimise the customer's recourse. We have read those documents, customers we work with have been burned by those documents, and we wrote ours to be structurally different. The intent is to publish what we will actually do, not what we reserve the right to do.

Three commitments structure everything below. First, we do not add capacity for unilateral termination beyond what is explicit in the AUP. If we cannot point to a specific clause that names your situation, we cannot terminate. Second, we do not write discretionary clauses that say "at our sole discretion" or equivalent. Discretion gets exercised; the language exists to give cover for arbitrary decisions. We avoid it. Third, we publish what we collect, what we retain, and for how long. Privacy policies that say "we may collect" rather than "we collect" are doing the same defensive expansion that we are trying to avoid.

The documents below are written by the engineers who run the service, not by external counsel optimising for the broadest possible interpretation. Counsel reviewed them; counsel did not draft them. The result is documents that operators can read and understand in a single sitting without a glossary. If something in any of the documents is ambiguous to you, ask on Telegram. We will either clarify or update the document to be clearer.

scope and jurisdiction

What the documents cover and what they do not.

The four documents together govern the operational relationship between us and customers. The Acceptable Use Policy lists what workloads we host and what we decline, including specific categorical exclusions (CSAM, malware command-and-control, phishing kits, DDoS-for-hire) and the operational thresholds for content that requires additional scrutiny. The Privacy Policy lists what data we collect and retain, what we do not log, and how we respond to legal process from each of our operating jurisdictions. The Terms of Service govern the contractual relationship: scope of service, payment, dispute resolution, and the limits of our operational responsibility. The Refund Policy lists what we refund and what we do not, with the reasoning behind each category.

Each document is governed by the laws of the specific jurisdiction where the customer infrastructure is racked. A customer with a VPS in Bulgaria operates under Bulgarian law for that VPS. A customer with infrastructure across Bulgaria and Iceland operates under each respective jurisdiction for each component. This multi-jurisdictional structure is intentional. It distributes legal-process risk across jurisdictions rather than concentrating it in a single choke point. The privacy SaaS case study in our case-study library documents how this structure absorbed two demand letters across an 18-month operational window without operational disruption.

change history

When documents change, we say why.

Every legal document carries a "last updated" date. Material changes are accompanied by a change summary at the top of the document explaining what changed and why. We do not update legal documents silently; we do not push terms changes by email at midnight on a Sunday; we do not require customers to accept new terms as a condition of continued service for minor clarifications.

For material changes that affect customer rights or our obligations, customers receive 30 days advance notice through their account contact and through a posted notice on this page. Customers who disagree with the proposed changes can terminate service with full pro-rata refund for the unused portion of their current billing period. We have made this commitment in writing because it constrains us in a way most hosting providers are not constrained, and it is structurally important for customer trust in a relationship where customer identity is intentionally minimised.

The most recent material change was March 2026, when we updated the AUP to clarify our handling of bulk-sender authentication requirements following the November 2025 Gmail enforcement transition and the April 2026 Microsoft enforcement completion. The change was technical and customer-favouring (we expanded the categories of legitimate bulk sending that we explicitly support), and it was not preceded by any customer-facing rule changes.

Legal framework philosophy applied across our policies

Our legal policies follow a specific philosophical framework that operators benefit from understanding to interpret the policies correctly. The framework reflects how we actually operate rather than defensive legal language that obscures operational reality.

Principle 1: minimum necessary data collection. Customer-facing data collection extends only to what operational requirements demand. The principle produces less data subject to legal-process exposure, less data subject to compliance frameworks, less data customers need to manage in their own privacy obligations. The principle has operational cost (we cannot provide some convenience features that would require data we deliberately do not collect) and operational value (we cannot be compelled to produce data that does not exist).

Principle 2: jurisdictional appropriateness. Our operations across seven jurisdictions follow each jurisdictions specific legal framework rather than imposing a unified policy that ignores jurisdictional differences. The approach produces operational complexity but matches the legal reality that policies need to align with actual jurisdictional law rather than aspirational unified policy.

Principle 3: customer-friendly enforcement. When ambiguity arises in policy application, we resolve toward customer-friendly outcomes rather than maximum policy enforcement. The principle reflects operational philosophy: customers are paying for services and benefit from policy interpretation that supports their legitimate use rather than restricting their use when restriction is not operationally necessary.

Principle 4: transparent process. Our legal policies document specific procedures rather than vague discretionary frameworks. Customers know what to expect when policies apply rather than depending on case-by-case discretionary decisions. The transparency supports customer planning and produces accountability for our own policy implementation.

Acceptable use policy operational specifics

Our acceptable use policy applies operational specifics that customers benefit from understanding before engaging services. The specifics below capture what the policy actually prohibits versus what marketing language might suggest is broader or narrower.

Categorical prohibitions: child sexual abuse material (always prohibited regardless of any other consideration), malware command-and-control infrastructure, phishing infrastructure targeting specific individuals or institutions, content used to defraud or harass specific identified victims, infrastructure supporting violent threats against specific individuals. These categories admit no exception under any circumstance.

Conditional prohibitions: content prohibited in the hosting jurisdiction but legal elsewhere (the customer needs to operate in a jurisdiction where the content is legal), bulk sending operations that produce concentrated complaint patterns (the operator needs to address the complaint patterns to remain in service), operations that produce sustained network attacks affecting other customers (the operations need to be modified to operate without affecting other customers).

Permitted but operationally cautioned: adult content that is legal in the hosting jurisdiction (we host this category but customers should understand the operational implications), cryptocurrency-related operations including exchanges and adjacent services (we host these but customers should understand evolving regulatory frameworks), political content including content critical of governments (we host these but customers should understand jurisdictional considerations affecting specific content).

Customer data protection across the policy framework

Customer data protection operates across multiple policies (privacy policy, data processing agreement, terms of service) with consistent underlying framework. The framework below describes how the policies interact rather than addressing each policy independently.

Data categories: customer identifying information (limited to what operational requirements demand), service usage data (operational logs retained per retention policies), payment data (cryptocurrency transaction records for accounting purposes), communication records (support interactions retained for service quality purposes). Each category has specific retention periods and access controls documented in the relevant policies.

Customer rights across the data: access rights (customers can request copies of their data), correction rights (customers can request correction of inaccurate data), deletion rights subject to operational and legal retention requirements (customers can request deletion of data not subject to retention obligations), portability rights (customers can receive their data in machine-readable format for transfer to other providers).

Legal-process responses: requests for customer data follow specific procedures documented in the privacy policy. The procedures require formal legal process from jurisdictions with authority over our operations; informal requests do not produce customer data. Customer notification of legal-process responses happens to the extent legally permitted; some legal processes prohibit notification, in which case we comply with the prohibition while documenting the response for the customer when notification becomes permitted.

Compliance framework alignment across our policies

Our legal policies align with multiple compliance frameworks that customers may need to address in their own operations. The alignment supports customers using our services as part of their broader compliance framework rather than requiring customers to address compliance gaps caused by our services.

GDPR alignment: our data processing follows GDPR Article 28 processor obligations. Customers subject to GDPR can use our services without creating additional GDPR exposure beyond their own controller obligations. The data processing agreement formalizes the processor relationship for customers requiring documented arrangements.

PCI DSS alignment: customers in scope of PCI DSS can use our services without expanding PCI DSS scope to our infrastructure when they avoid processing card data through our services. Customers needing PCI DSS scope expansion (rare but occasional) require additional engagement to formalize the arrangement.

SOC 2 alignment: customers operating SOC 2 compliance programs can use our services as part of their controls. We provide evidence packages supporting SOC 2 control documentation; the evidence is sufficient for customer auditor review without requiring auditor engagement with us directly.

ISO 27001 alignment: similar alignment to SOC 2 with adjusted documentation conventions matching ISO 27001 framework requirements. Customers operating ISO 27001 certified programs can integrate our services without compliance gaps.

HIPAA alignment: limited; we do not handle protected health information in customer-accessible services. Customers needing HIPAA-covered services should evaluate other providers; our services are not appropriate for healthcare data processing.

Industry-specific frameworks: customer-side compliance frameworks beyond the general frameworks above are evaluated case-by-case. Most industry frameworks have analogs to the general frameworks; specific requirements occasionally need additional documentation work.

Customer responsibilities under our policy framework

Customer responsibilities under our policies are explicit rather than implicit. The clarity protects both customers (who know what they need to do) and our operations (which depend on customers fulfilling their responsibilities).

Responsibility 1: lawful operation under customer jurisdictional framework. Customers are responsible for ensuring their operations are lawful in their own jurisdictions. We do not evaluate customer operations against every possible jurisdictional framework; customers operate under the laws applicable to their situation and accept responsibility for compliance with those laws.

Responsibility 2: appropriate authorization for all sending. Customers must have legal authorization to send to their recipients (opt-in for marketing, legitimate business interest for B2B, account-related communications for transactional). We do not audit recipient authorization; customers accept responsibility for ensuring authorization exists.

Responsibility 3: content compliance with applicable frameworks. Customer content must comply with applicable advertising regulations, consumer protection requirements, industry-specific frameworks. We do not pre-approve customer content; customers are responsible for content compliance.

Responsibility 4: appropriate handling of customer-side data. Customer-side data (recipient lists, customer data, business operational data) is the customer responsibility regardless of where it processes. Customer handling of this data must comply with applicable data protection frameworks.

Responsibility 5: incident response coordination. When incidents occur affecting customer operations, customers participate in incident response as required. Customer-side actions during incidents are often required for resolution; we cannot resolve all incidents independently of customer participation.

Policy update history and ongoing review processes

Our legal policies undergo periodic review and occasional updates. The update history below reflects the timing and nature of significant policy changes; routine clarification updates that do not change policy substance occur more frequently than the major updates listed.

Major policy updates 2024-2026: GDPR compliance updates following CJEU decisions affecting third-country transfer mechanisms (2023, 2024), Digital Services Act compliance updates for relevant policies (2024-2025), AI Act considerations for any automated processing components (2025), MiCA framework updates affecting cryptocurrency-related operations (2024-2025), evolving sanctions compliance frameworks (ongoing throughout 2024-2026).

Review cadence: comprehensive review of all policies annually with focused review of specific policies when external developments warrant. Comprehensive reviews cover the full policy set with cross-policy consistency checking. Focused reviews address specific policies affected by specific developments without requiring full set review.

Customer notification of policy changes: notifications follow specific patterns based on the nature of changes. Substantive changes affecting customer obligations or rights generate explicit customer notifications through email and in-product communication. Clarification updates that do not change policy substance update the policies without explicit notification. The notification policy balances customer awareness against notification fatigue from frequent minor updates.

Customer feedback on policies: we accept customer feedback on policies through standard support channels. Feedback that identifies genuine policy issues feeds into the review cycles; feedback that reflects preferences different from our policy choices receives acknowledgment without policy change. The pattern reflects that policies need to serve broad customer base rather than every individual customer preference.

Legal counsel review: external legal counsel review of policy changes happens for substantive updates. Routine clarification updates do not require external review. The review pattern balances cost against operational appropriateness; routine updates with clear precedents do not warrant external review while novel issues do warrant it.

Legal process response patterns and customer notification

Legal process responses follow specific patterns documented in the privacy policy. The patterns balance our legal obligations to comply with valid legal process against customer interest in being notified of legal-process actions affecting their data.

Pattern 1: domestic legal process from the hosting jurisdiction. Valid local court orders from the jurisdiction where the affected data resides receive response per local legal requirements. The response scope is limited to what the court order specifies; we do not exceed the documented scope. Customer notification happens unless the order prohibits notification.

Pattern 2: cross-jurisdiction legal process through MLAT mechanisms. Foreign legal process pursued through mutual legal assistance treaty cooperation receives response after local authority review of the request. The MLAT process produces additional review beyond what direct foreign legal process would receive; many cross-jurisdiction requests are declined or substantially narrowed during the MLAT review.

Pattern 3: informal foreign government requests. Requests from foreign governments without proper legal process do not produce customer data. The request receives acknowledgment indicating the proper process required; if the requesting authority follows up through proper channels, we respond per the applicable process.

Pattern 4: civil legal process. Civil legal process from any jurisdiction requires the requesting party to follow proper procedures including court action where applicable. We do not respond to informal civil requests; the procedure exists to protect customer interests against parties attempting to obtain data without proper authority.

Customer notification policy: we notify customers of legal-process actions affecting their data unless prohibited by the specific legal process. Notification timing varies based on the action; immediate notification happens for actions allowing it, delayed notification happens after gag orders expire for actions requiring confidentiality during specific periods.

Documentation of legal-process responses: we maintain records of legal-process actions sufficient for our own legal obligations and for customer notification when the customer becomes notifiable. The records are not generally accessible; specific customers can request records relating to their own data through standard support channels.

Cross-jurisdiction policy interaction patterns

Our multi-jurisdictional operations face cross-jurisdiction policy interaction patterns that single-jurisdiction operations do not. The patterns matter when customer operations span multiple jurisdictions or when our service operations span multiple jurisdictions.

Pattern 1: data residency across jurisdictions. Some compliance frameworks impose data residency requirements that affect where data physically resides. Customer-side data residency requirements are accommodated through jurisdiction-specific service configuration; the configuration is documented per customer when residency requirements apply.

Pattern 2: regulatory framework alignment across operations. Different aspects of customer operations may face different regulatory frameworks. Customer-side payment infrastructure may face MiCA framework; customer-side data processing may face GDPR; customer-side content may face Digital Services Act framework. Our service configuration accommodates the relevant frameworks per customer situation.

Policy interpretation in ambiguous situations

Policy interpretation in ambiguous situations follows specific patterns documented above. The summary patterns reflect operational reality rather than legal formality.

Ambiguity resolution: when policy language could support multiple interpretations and the interpretations differ in customer-favorable versus restrictive directions, we resolve toward customer-favorable interpretation. The pattern reflects operational philosophy that customers are paying for services rather than being subjected to maximum policy enforcement.

common questions

Questions we receive about the legal documents.

Do you have a corporate entity I can sue?

Yes. Operations run through an entity registered in a specific jurisdiction with appropriate banking, tax, and legal infrastructure. The entity name and registration details are disclosed during customer onboarding under NDA and are available to any party with a legitimate legal process or contractual dispute. We do not publish the entity name on this site because doing so concentrates targeting on the corporate name, which is not in the customer's interest either. Customers who need the entity disclosed before signing up can request it through Telegram or ticket.

What jurisdiction governs disputes?

The Terms of Service specify the governing law and venue. Disputes are governed by the law of the jurisdiction where the customer infrastructure is racked, with venue at the appropriate court in that jurisdiction. For customers with infrastructure across multiple jurisdictions, the relevant jurisdiction for any specific dispute is the one where the infrastructure subject to the dispute resides. This is the arrangement most consistent with how legal process actually operates against hosting providers and avoids forum-shopping incentives that artificial governing-law clauses would create.

How do you handle court orders for customer data?

Court orders from the jurisdiction where the customer infrastructure resides are honoured. We require the order to be properly issued, properly served, and properly scoped to specific data we actually retain. We do not honour court orders from jurisdictions that lack direct authority over our operations, regardless of how those orders are framed. Court orders requesting data we do not retain (such as web access logs we never collected) receive an attestation that the data does not exist rather than a fabricated response. The Privacy Policy documents the specific categories of data we retain and for how long.

What happens if my account is suspended for AUP violation?

Suspension procedures are documented in the AUP. The short version: for ambiguous cases we contact the customer through their account contact and request information or remediation before any suspension. For unambiguous violations (the categorical exclusions like CSAM or malware C2) suspension is immediate without prior contact. For all other cases we document the specific clause being applied, the specific evidence supporting the determination, and the remediation steps that would lift the suspension. Customers who dispute a suspension have a written appeal process documented in the Terms of Service.

Do the legal documents change frequently?

Material changes are rare, typically once or twice per year. Minor clarifications (typo fixes, terminology updates that do not affect substantive meaning) happen more frequently and are tracked in document version history without customer notification. Material changes that affect customer rights or our obligations receive 30 days advance notice with the right to terminate for full pro-rata refund. The last material change was March 2026 and the next is not currently scheduled.