The Austrian Cloud Is a Chain of Custody: Where myDataCenter.at's Locality Promise Actually Ends

Summary

• The legal and operational identity is provable: myDC Cloud Services GmbH is the Austrian company behind the myDataCenter.at brand, not simply a label for a larger hosting group.
• Its cloud offering combines KVM virtual machines, Ceph-based storage, a client dashboard, optional backup, and a claim of a data centre in Vienna; each component reduces one type of dependency while creating another operational boundary that buyers must inspect.
• The public storefront makes small deployments readable, but it is the terms and conditions—not the displayed monthly price—that define the real economics via contract duration, notice period, energy-related adjustments, support scope and limited remedies.
• Locality is myDC's primary differentiator and its most difficult claim to substantiate. Public evidence confirms an Austrian operational footprint but does not disclose enough about facility identity, storage failure domains, replica location, service levels or certificate scope for a serious buyer to stop at 'data in Austria'.

Follow a click through the service

Imagine an Austrian software company ordering a new production server. An administrator enters the myDataCenter.at dashboard, chooses 'Platform Vienna', selects CPU cores, memory and storage, attaches a private network, provides an SSH public key, and pays. The machine appears quickly enough that the transaction feels like a single act. It is not. That click traverses a chain of custody.

The first link is legal. The customer contracts with myDC Cloud Services GmbH, a registered company in Krems, not with a generic 'Austrian cloud' and, according to available evidence, not with a large international parent. The second link is the service control plane: myDC's shop, account system, provisioning workflow, invoices, tickets and status display. The third is technical: a virtual machine running under KVM, with its disks placed on a Ceph storage system and high-availability logic intended to restart workloads if a compute node fails.

The fourth is physical: power, cooling, fire protection, access control and fibre at a facility in Vienna. The fifth is external: the networks, operators, software communities, payment providers and specialised implementation partners that a small operator inevitably relies on.

MyDC's value is therefore not to abolish dependency. No cloud does that. It lies in the fact that it can transform a sprawling set of dependencies into a smaller, geographically bounded and humanly navigable service. It is a useful product for an organisation that considers Austrian guardianship, German-language support or access to an accountable local operator more important than a huge catalogue of proprietary managed services. But this only works if the boundaries are precisely described.

The company's public material is unusually concrete in places. Itscloud pageidentifies KVM, Ceph, AMD EPYC processors, internal and external network caps, snapshots, rescue access and optional backup. Itsorder guideexplains what a customer must provide. Itsterms and conditionsspecify support hours, notice periods, maintenance handling, remedies and price adjustment logic. These documents allow a more serious assessment than the usual sovereign cloud slogan.

They also reveal the central tension. MyDC markets immediacy and flexibility at the interface, while its legal and physical foundations are necessarily slower and more fixed. A virtual machine can be resized or deleted in a dashboard; the contract behind it may have a minimum term and a three-month notice period. A Ceph cluster can redistribute data after a disk failure; that in itself says nothing about whether all replicas share the same room, power domain or metropolitan risk. A dashboard can display green lights; the terms exclude maintenance from certain remedies and provide no detailed public incident history.

The useful unit of analysis is not the server. It is the chain.

The GmbH behind the domain

The identity bridge is solid enough to support the article's boundary. The provider'sImprint and terms and conditionsnamemyDC Cloud Services GmbHand explicitly state that it provides services under the brandmyDataCenter.at. They give the registered address at Dr.-Franz-Wilhelm-Straße 2 in 3500 Krems an der Donau, name Robert Siedl as managing director, and provide the company register number FN 533177i and VAT number ATU75570758. The same page specifies that the company provides infrastructure, platform and software services from a data centre in Vienna using its own hardware, with customer data stored in Austria.

An independent public registration from theAustrian Federal Economic Chamberlinks the same legal name, trading brand, domain, address, register number and managing director. It records the business authorisation for information technology services since 19 June 2020. This cross-check is important. It rules out the easy mistake of treating myDataCenter.at as a product page without a clear contracting entity, or of silently substituting a better-known facility or service partner for the company being assessed.

The operator's owncompany historyadds a lineage that is relevant but must be attributed as a corporate narrative. It states that the founders took over an existing cloud business from Siedl Networks via an asset sale in 2019 and created a separate company around the myDataCenter.at brand. The timeline describes earlier infrastructure work dating to 2015, a larger cluster and online store in 2020, customer self-provisioning in 2022, monitoring and Zimbra services in 2023, integrated billing in 2024, and a partner programme in 2025. This is evidence of continuity of service knowledge, but not proof that every deployment, customer or operational claim before 2020 belongs to the current GmbH.

This distinction becomes important when public case material presents both names. ASchoolFox success storydescribes myDataCenter resources while attributing consulting, migration, implementation and ongoing operational support to Siedl Networks. A 2024 compilation from theWKO Open Source Experts Grouprepublishes the case. Robert Siedl appears in the orbit of both companies, but the sources examined do not establish a current ownership link that would justify merging them. The defensible reading is narrower: myDC is the contractual and cloud infrastructure subject; Siedl Networks is an implementation and support partner named in at least one documented deployment.

This accuracy is not legal pedantry. It tells a buyer where to address a due diligence request, which party should appear in the data processing agreement, who is responsible for the virtual infrastructure layer, and where a systems integrator's duties begin. 'Local' is only useful when accountability has a name and a register number.

What Platform Vienna actually gives a customer

MyDC's current cloud range is deliberately narrow. 'Platform Vienna' is the more complete private cloud building block; 'Server Vienna' is the simpler virtual server offering. Aproduct restructuring notice published in August 2025states that these offerings replaced the old fixed packages so that CPU, memory, SSD or NVMe storage, network capacity and add-ons can be selected more freely. Existing configurations were to continue unchanged.

Thecurrent comparisonindicates that both products use KVM rather than operating-system containers, run on AMD EPYC processors, and store virtual disks in Ceph. The provider describes the virtual machines as highly available. Customers receive root access via SSH or RDP and can use snapshots, tasks, a rescue system and a basic firewall through the dashboard. Platform Vienna adds private networks and advertises internal connectivity of up to 10 Gbit/s; external connectivity is listed at up to 1 Gbit/s. An IPv6 /64 is available. 'Up to' is a cap, not a guaranteed throughput level, and the public page does not disclose contention ratios, packets per second limits or a network service level.

The store makes the commercial abstraction tangible. On 17 July 2026, thePlatform Vienna storefrontdisplayed a starting monthly price of €46.60, while Server Vienna started at €8.70; the terms and conditions specify that commercial prices quoted are exclusive of VAT. A configuration view offered cores, memory, storage, connectivity, IPv4 addresses, VLANs and backup with individual prices. These observations are a dated snapshot of the storefront rather than a permanent price list. They are useful because they show the selling unit: myDC does not present a hyperscale metered-consumption environment with hundreds of services. It sells configurable virtual infrastructure with visible monthly components.

Ordering is not fully automatic. According to the company'sknowledge base guide, a customer chooses monthly, quarterly or yearly billing, then pays by account credit, bank transfer or PayPal. Credit or PayPal can trigger immediate provisioning where the product allows it; automatic provisioning after a bank transfer requires account verification. The buyer provides a hostname, an operating system template and an SSH public key. MyDC states it deliberately avoids generated or default passwords. Platform customers then select additional processors, memory, boot disk support, public addresses, private networks and backup storage.

This workflow situates the line between infrastructure and administration. MyDC can instantiate a virtual machine, attach networks and provide a rescue path. The customer remains responsible for the guest operating system, applications, identity design, patching, secrets and much of the firewall policy unless they purchase additional management. The public knowledge base contains instructions for OPNsense, pfSense, MikroTik and common Linux or Windows tasks, which is useful evidence of the work customers actually encounter. It is also evidence that the 'cloud' does not eliminate system administration.

Buyers should distinguish the two product families more sharply than the marketing table does. A buyer should ask whether a particular CPU allocation is dedicated or shared, how overcommitment is managed, what storage performance is guaranteed, whether live migration or only restart recovery is offered, and whether Platform private networks span more than one physical failure domain. None of these answers should be guessed from the presence of familiar open-source components.

KVM and Ceph shift the boundary of proprietary lock-in

The architecture uses recognisable, non-proprietary building blocks. This is significant. KVM is the mainstream virtualisation mechanism of the Linux kernel, and myDC states that its service provides fully virtualised machines rather than containers. Ceph is a distributed storage system designed to place and replicate data across object storage daemons. TheCeph architecture documentationexplains that monitors maintain the cluster map, OSDs store and replicate entities, and the CRUSH algorithm maps data to failure domains without a central lookup bottleneck.

These components can reduce one form of switching cost. A customer does not write an application directly against a single database API or event service just to run an ordinary virtual machine. Linux, Windows, a virtual firewall or a database server can in principle run on another KVM-based platform. MyDC's public commitment to open standards and migration support reinforces this direction. But 'uses open source' and 'has a tested exit path' are not synonymous.

The provider does not publish which disk image formats are available for export, the mechanisms or cost of a full volume export, bandwidth allocations during migration, configuration export for networks and firewall rules, or snapshot handling. It does not publish an infrastructure-as-code interface on the cloud page. A dashboard operation that creates a server may therefore remain a manual control-plane dependency even when the workload itself is portable.

Before relying on low lock-in, a buyer should ask myDC to export a representative machine and its network settings, import them elsewhere, start the copy, and record the elapsed time, data transfer cost and required changes.

Ceph also illustrates why a product name is not an assurance. Ceph can replicate entities across multiple hosts and can encode a hierarchy of devices, racks, rows and rooms in a CRUSH map. Its own documentation warns that availability depends on monitor quorum, replication settings and failure domain configuration; it recommends three copies for high availability rather than treating any Ceph installation as automatically resilient. MyDC's public material does not disclose its number of monitors, OSD nodes, replica count,min_size, placement rules, rack distribution, encryption configuration, usable capacity or rebuild margin.

This absence does not show a weak cluster. It shows that the claim remains at the product description level. The correct procurement question is not 'Do you use Ceph?' but 'Show how this customer's pool is placed, what simultaneous failures it tolerates, and what happens to latency and recovery time during a rebuild.' If replicas are on different disks in different hosts but share the same room and power, the system is resilient to a disk or host failure, but not to a site failure.

The same discipline applies to high availability. MyDC's 2025 product notice explains that when a host fails, an affected virtual machine can automatically start on another piece of hardware. This is useful infrastructure recovery. It is not continuous application availability: the guest must restart, applications must recover, and any in-flight state may be lost. A customer requiring near-zero interruption still needs application clustering, replicated state, health checks and traffic failover above the virtual machine layer.

'HA' must therefore be translated into a measured recovery-time distribution for the workload, and not left as a badge.

There is a second architectural question in the difference between Platform Vienna and Server Vienna. Private networks of up to 10 Gbit/s can make Platform suitable for multi-tier systems, storage traffic or hybrid links. Server Vienna appears intended for simpler, publicly connected instances. A buyer who starts on the cheaper server and later needs private segmentation must verify whether conversion is possible without a rebuild. Product simplicity is valuable, but only if the upgrade path is explicit.

The dashboard is both convenience and concentration

MyDC has invested in making a small infrastructure estate controllable through a single client interface. AMay 2025 dashboard announcementstates that customers can order, manage, modify and cancel services; view network status; create support tickets; read documentation; and manage invoices in one place. It also states that the login supports two-factor authentication. AJanuary 2024 versionintroduced service monitoring and a network status view.

For a small IT team, this consolidation is part of the product. The alternative is often not a perfectly automated hyperscale operation but a mix of hosting portals, email modifications, spreadsheets and calls to multiple providers. A local dashboard that links ordering, technical status and support can reduce coordination costs.

It also concentrates authority. An account that can add, modify or delete services—and see invoices and support information—is a material control surface. Two-factor authentication is therefore a baseline, not a complete security story. Buyers must verify whether it can be enforced for every account, which factors are supported, whether roles separate billing from administration, how API or service credentials are scoped, how sessions and recovery are handled, whether administrative events are exportable, and how provider staff access is approved and logged.

The public pages do not describe a client API, command-line tool, Terraform provider, single sign-on integration, role-based access model or immutable audit export. Some may be available on request; the evidence pack does not establish them. Their absence in public documentation matters most for customers who want reproducible infrastructure and least for those who deliberately buy a ticket-assisted personal operational model.

The dashboard service status also requires interpretation. It may show what myDC chooses to monitor and expose, which is better than no status surface. It cannot by itself establish end-to-end application health, historical compliance with a service level or a complete incident record. A serious customer should connect their own synthetic probes from outside the provider's network and reconcile them with the dashboard after every material event.

The room in Vienna is a dependency, not a footnote

MyDC states that its hardware and customer data are in Austria. Itsfacility descriptionplaces the operation in Vienna and describes redundant power, UPS and generators, cooling, fire detection and suppression, biometric access, video surveillance, patrols and renewable electricity. It states that multiple dark fibre paths reach two major Austrian network nodes, that sites are connected by a fibre ring, and that the data centre is ISO 27001 certified. The same page touts availability 'up to' over 99.99%.

These are company assertions. The public page does not name the facility, identify the certificate holder, give a certificate number or scope, define which service gets which availability level, or locate the additional sites and backup replicas. This leaves a significant evidence gap between 'Vienna' and a usable resilience model.

Public network evidence narrows the likely operational environment without bridging the gap. On 17 July 2026, the myDataCenter dashboard resolved an address block identified by RIPE registration data as SIEDL-NETWORKS, while a Zimbra mydc.at hostname resolved a range routed by Nessus.BGP.tools' current view of AS47692identifies the autonomous system as Nessus GmbH and shows multiple upstream networks. Separately,Nessus names 'MyDC Cloud Services' as a customerand operates multiple data centres in Vienna.

These are one-off external pieces of evidence of a network or facility relationship. They are not proof that every myDC virtual machine uses a particular address, operator or building. DNS may only represent a control-plane service; addresses and routes change; a customer may use their own prefixes or links. The evidence supports a procurement question, not an architectural statement.

The wording of myDC's facility description closely resembles the public description of Nessus'sNDC1, including the dark fibre routes to two Austrian nodes and the physical security controls. Nessus'shousing overviewstates that its Vienna facilities are carrier-neutral and ISO 27001 certified. Yet myDC does not name NDC1 on its own page, and Nessus now describes three facilities with different specifications. It would be speculative to infer the exact site, rack, certificate scope or second replica location from similar wording.

Why does the distinction matter if all candidates are in Vienna? Because 'Austria only' is a jurisdictional boundary, not a disaster recovery boundary. Two racks in the same building, two buildings on the same campus, and two metropolitan sites on different power and flood domains offer different resilience. A fibre ring may still share common conduits or aggregation points. Multiple operators may still share an autonomous system or an exchange.

A buyer must obtain a map of physical and logical dependencies under confidentiality if necessary: primary and secondary sites, power domains, meet-me rooms, access accountability, IP transit, DDoS path, control plane hosting, monitoring, and every subcontractor that can touch customer data.

The network also determines what locality cannot solve. Traffic between an Austrian user and a Vienna workload may remain domestic, but only a route measurement can show the actual path at a given moment. Traffic from global users will traverse foreign networks. Upstream failures, route leaks and denial-of-service attacks do not respect a national boundary. MyDC's terms acknowledge that connectivity to other networks cannot be guaranteed and allow temporary disconnection of an attacked service when it threatens other services.

The optional DDoS product in the storefront is therefore part of service design, not a decorative add-on for internet-exposed systems.

Locality still has value. It can simplify site visits, contract jurisdiction, latency for Austrian users, data location explanations and communication during an outage. But it is strongest when presented as a bounded operational choice—named sites, named subcontractors, measured routes and tested recovery—not as the assertion that geography eliminates infrastructure risk.

Backup creates a second sovereignty map

MyDC exposes two related but separate backup ideas. Virtual machine backup can be added to Platform Vienna; the 2025 restructuring notice states that backups are replicated across two sites and can be restored via the dashboard. Separately, the company sells aManaged Proxmox Backup Servicefor protecting the customer's Proxmox environment. The storefront displayed a starting price of €25 per month on 17 July 2026 and described scalable storage, push or pull jobs, virtual machine restore, file backup for Linux, verification and optional encryption.

Implementation guides are more revealing than the product sheet. For myDC to pull from an on-premises Proxmox Backup Server, the customer needs a static public address and must make port 8007 reachable from myDataCenter. Thedashboard setup guidestrongly recommends restricting access to myDC's public address. It tells the customer to create a local account with at least theDatastoreReaderrole, exchange a datastore fingerprint, set the remote location and schedule a pull sync. Retention can be modified; individual backups can be protected against deletion by ordinary retention.

The reverse integration is also possible. Thelocal server guideexplains how a customer uses the hostname, account, password and fingerprint exposed in the dashboard to connect the myDC datastore as a remote. A separateverification guidetells customers to schedule integrity checks and inspect logs.

This is a credible operational workflow because it exposes responsibilities. The customer provides stable connectivity, restricts source addresses, creates least-privilege credentials, verifies the endpoint fingerprint, chooses schedules and reviews logs. MyDC provides the remote storage and the control interface. Theupstream Proxmox Backup Server documentationconfirms that the software supports access control, two-factor authentication, client-side encryption, verification, retention, remote sync and restore operations. It does not establish which of these controls myDC enables by default or manages for a particular customer.

Backup modifies the sovereignty map because a copy has its own location, encryption keys, credentials, retention rules and egress requirements. 'Replicated across two sites' is not enough for procurement. The buyer must know whether the two sites are in separate buildings and power domains; whether the backup plane shares identity, network and personnel with production; who holds the encryption keys; whether protected snapshots are immutable against a compromised administrator; what deletion delay applies; how often full restores are tested; and what recovery time is realistic for the largest dataset on the purchased bandwidth.

There is also a concentration trade-off. Sending an on-premises Proxmox backup to myDC creates useful geographic separation. Backing up a myDC virtual machine into a repository that shares the same provider, city, control account or network may still protect against logical deletion and host failure, but may be weaker against provider-scale or metro-scale events. A third copy in a different failure domain may improve resilience, even if it complicates an Austria-only policy. Sovereignty and recoverability are objectives to balance, not interchangeable labels.

Personal support is part of the architecture

MyDC's likely advantage over a larger commodity host is not a secret storage algorithm. It is the reduction of organisational distance. Thesupport pagepublishes weekday telephone hours, while the terms define ordinary support as Monday to Friday, 08:00–12:00 and 13:00–16:45. Customers who have purchased 24/7 support receive a separate emergency number with their credentials. This is a clearer distinction than a generic statement that infrastructure is continuously monitored.

The distinction should guide workload placement. A small company with systems running during office hours may value access to people who know their environment more than overnight telephone cover. A public-sector body with revenue or safety impact at midnight needs the paid escalation path, response and restoration commitments in writing. '24/7 operations' may mean that alarms are monitored; it does not necessarily mean that a customer can reach an engineer at the standard price, or that the engineer must restore service within a defined time.

Thepartner pagenames Siedl Networks, PLP Datentechnik, Genius IT, Compution IT and bavarialogy as organisations that can help with setup, operation and maintenance. AJuly 2026 announcement about bavarialogystates that this partner uses Platform Vienna and Server Vienna for client work. These are provider statements, not independent measurements of customer outcomes, but they demonstrate the intended operational model: myDC supplies infrastructure and a network of regional specialists can supply the application and administration layer.

The SchoolFox case makes this allocation concrete. The vendor-produced document states that the deployment used myDataCenter cloud resources with an open-source stack including Univention Corporate Server, Zimbra, IKARUS and OPNsense. Siedl Networks provided consulting, migration and commissioning and continued to provide operation and support. The customer quote reports easier administration and collaboration, but the case does not publish any availability, performance, cost or migration metrics. It is evidence of an implementation pattern, not statistical evidence of service quality.

For a buyer, the central question is who owns the incident at each layer. If an application is slow, does myDC prove compute and storage performance while the partner inspects the guest and database? Who coordinates when neither sees a fault? Does the customer open one ticket or two? Are partner actions visible in the myDC audit trail? Can another partner take over without a rebuild? A local ecosystem can reduce response friction, but an ambiguous accountability matrix can recreate the same coordination problem it is supposed to solve.

The monthly price is not the economic contract

The storefront invites comparison by the displayed monthly price. The terms and conditions define a different unit: the relationship over time. MyDC'sOctober 2023 terms and conditionsapply to businesses and state that each product forms a separate contract. Unless otherwise agreed, the minimum term is twelve months or a longer billing period selected in the store; the contract then renews for the same period. Ordinary cancellation must reach them by signed letter at least three months before expiry.

The order guide offers monthly, quarterly and annual billing. A monthly billing interval should not be taken as a one-month commitment, because billing cadence and minimum contract term are different concepts in the public documents. A buyer should ensure that the order confirmation clearly states both dates: service start, end of minimum term, notice deadline and renewal period. If the live checkout offers different conditions from the terms, the signed or saved order record should resolve the conflict.

The same terms require invoices to be paid in advance within fourteen days and allow suspension after a grace period. If the customer causes early termination, the remaining fees may become due. Work outside ordinary support hours and troubleshooting caused by the customer may be billed separately. These clauses are fairly normal for a small business provider, but they make the cheapest virtual machine card an incomplete cost estimate.

Energy is a particularly explicit input. MyDC reserves the right to adjust prices with notice and includes a formula linked to wholesale electricity indicators when the quarterly average rises by at least five per cent. The customer receives a special termination right if the resulting increase exceeds thirty per cent; other annual adjustments may follow a minimum percentage, consumer prices or collective wage changes without the same exit right. The exact clause must be reviewed in the authoritative German text rather than reduced to a single percentage.

Its strategic meaning is clearer: local cloud pricing remains exposed to energy, labour and facility economics, and myDC passes on some of that volatility rather than pretending infrastructure is costless.

The remedy side is modest. The terms do not promise uninterrupted access, any desired external connection or the survival of any equipment or data. They allow planned maintenance and urgent work, and state that maintenance-related restrictions do not automatically create a fee reduction or warranty claim. Troubleshooting starts during office hours in the standard level. For delayed initial delivery, the standard credit stated is €13 per week from the third week only, subject to exclusions such as third-party delay.

Liability for ordinary negligence is limited, indirect damages and lost profit are excluded, and total damages are capped at €20,000 under the published terms, subject to the usual legal exceptions that cannot be contracted away. The terms also allow temporary suspension of a service under denial-of-service attack if it affects others, with attack-related costs possibly charged to the customer. These provisions may be perfectly acceptable for a small internal system and totally inadequate for a revenue-critical platform.

This is why price comparison should use a workload scenario rather than a server card. Include compute, memory, storage growth, public addresses, private networks, backup capacity, retention, DDoS protection, licences, partner administration, premium support, data transfer for normal usage and egress, customer labour, and the cost of a recovery test. Then assess the contractual downside: what an hour, day and week of downtime would cost, against the remedy actually offered.

MyDC's economic sweet spot is probably a buyer for whom the provider's small size and personal access reduce management costs enough to compensate for less automation and less contractual standardisation. The public evidence does not reveal revenue, customer concentration, headcount, margins or investment capacity, so it cannot support a judgment on financial resilience. A critical buyer should ask for appropriate financial or continuity assurances privately rather than infer them from a low monthly starting price or a list of customer logos.

Exit is easier at the workload level than at the service level

MyDC says it favours open standards and avoids lock-in. The architecture supports part of that claim. Ordinary KVM virtual machines, conventional IP networking and Proxmox-compatible backups are in principle more portable than an application assembled from proprietary serverless services and managed data services. The company also says it helps customers migrate.

Operational exit still has at least four parts. First, extracting data and machine images in an agreed format. Second, reproducing networks, firewall rules, addresses, DNS, certificates and monitoring at the destination. Third, transferring or recreating backup history and proving a restore. Fourth, terminating each product contract before its distinct deadline. Open-source software mainly helps with the first two; it does not complete them.

Address continuity is a frequent hidden cost. An IPv4 public address supplied by myDC may not follow the customer. Applications, remote firewalls, allowlists and third-party integrations may be embedded. The order and backup guides themselves show why: a backup relationship may depend on a static public source address. Migration may require parallel operation while each peer is updated, which means paying both providers and managing data consistency.

The dashboard is similar. Invoices and tickets may be downloadable or retained only through the existing export and account closure process. Audit history, monitoring data and configuration state must be exported before deletion. The public documentation does not specify how long terminated service data or account records remain recoverable, or how deletion is proved.

The discontinued Kopano service offers a useful, non-catastrophic example of upstream dependency. In aNovember 2024 notice, myDC stated that Kopano's vendor would discontinue the affected product in March 2025, so myDC would cease its managed offering and recommend Zimbra. It offered existing customers migration of emails, calendars, contacts and tasks at no charge. This is evidence of a responsible transition response. It is also a reminder that a local provider does not control every upstream product lifecycle.

A procurement-level exit test should take place before production, when leverage and goodwill are highest. Export a representative virtual machine, restore a backup outside myDC, recreate a private network, rotate all credentials, and request a draft deletion certificate. Record the dependencies that do not transfer. Repeat the exercise after major architectural changes. If the provider facilitates this test, its open standards promise becomes evidence rather than positioning.

Security labels have different owners and scopes

MyDC's public security story contains several good controls. The company states that its dashboard supports two-factor authentication. The ordering flow uses SSH public keys provided by the customer instead of standard or generated passwords. The facility description covers physical access, monitoring, fire suppression, power and cooling. The backup workflow recommends source address restriction and fingerprint verification. The terms acknowledge denial-of-service response, and the storefront offers a dedicated protection option.

These controls do not automatically add up to a certified information security management system for myDC Cloud Services GmbH. The company states that thedata centreis ISO 27001 certified. ISO explains thatISO/IEC 27001specifies requirements for an information security management system. The value of a certificate depends on its named holder, sites, services, exclusions, version, issuing body and validity. A facility operator's certificate can provide significant inherited assurance without certifying myDC's own personnel processes, dashboard development, support access or customer service scope.

MyDC also states that it has renewed an Austrian Cyber Trust label. The label's ownprogramme descriptionoffers several assurance levels and positions its standard label as a pragmatic entry point. The2026 programme rulesare particularly useful: the scope is tied to the registered company and the systems, processes and personnel under its control; the standard level relies on validated self-declaration, while the highest level requires external audit; labels are time-limited; and the programme does not promise absolute security. Without a public certificate record or level in the evidence examined, it would be wrong to elevate 'Cyber Trust' into a claim equivalent to an independently audited ISO certification.

The public evidence gaps are as important as the visible badges. The pages examined do not provide a myDC ISO certificate, statement of applicability, penetration test summary, vulnerability disclosure pathway, subcontractor list, encryption-at-rest specification for cloud disks, security incident notification objective, recovery objectives, personnel access control description or customer audit pack. This does not mean these documents do not exist. It means a regulated or high-impact buyer should ask for them.

For personal data, European law gives weight to the contract and operational design.Article 28 of the GDPRrequires controller-to-processor clauses covering instructions, confidentiality, subcontractors, security assistance, deletion or return and audit information; Article 32 requires risk-appropriate security including resilience and timely restoration where relevant. 'All data in Austria' can simplify one part of the transfer analysis, but it does not replace these obligations nor does it establish that every support, telemetry, payment or communications sub-service remains within the same boundary.

Financial entities face a more demanding test under theDigital Operational Resilience Act (DORA). DORA's ICT third-party contracting provisions require clear descriptions of services, data processing and storage locations, availability and integrity commitments, incident support, audit and access rights, continuity support and exit clauses, with additional requirements for critical or important functions. A partner announcement that invokes DORA or NIS2 is a marketing claim until the underlying contract, controls and evidence meet the customer's obligations.

The most credible security posture for myDC would therefore be deliberately layered: identify the controls operated by the GmbH, controls inherited from the facility and network provider, controls inherent in Ceph or Proxmox but dependent on configuration, controls delegated to implementation partners, and controls retained by the customer. A one-page shared-responsibility matrix would be more valuable than a longer list of unbounded security names.

A green status page is a snapshot, not a history

On 17 July 2026, myDC's publicnetwork status pagedisplayed listed services as operational and reported 100% figures for its visible monitors. The page states that availability is measured over one year and excludes maintenance. Its public RSS feed showed no ongoing incident entries at the time of review.

This supports only a narrow verified statement: the provider was not publicly reporting an active problem at that snapshot. It does not establish that no incidents occurred during the year. The visible history did not expose a complete, easily verifiable timeline of events, and excluding maintenance can make an availability percentage unsuitable for the customer's end-to-end calculation. No credible public source in the frozen evidence set established a material myDC outage; the absence of a surfaced incident is not proof of incident-free service.

The company has at least published evidence of physical resilience tests. AMarch 2024 maintenance noticeannounced a 'black building' test during which normal power would be interrupted and UPS and generator systems activated; myDC stated it did not expect customer interruption. Publishing the plan is positive. The examined material did not include a post-action report with measured transfer performance or anomalies.

For a buyer, the strongest test is to ask for twelve or twenty-four months of incident and maintenance records, including events that did not breach contractual thresholds. Compare them with external monitoring. Ask for detection time, communication time, mitigation time, layers affected, root cause, corrective actions and recurrence. Also ask how emergency maintenance, upstream network failure, DDoS isolation and partial storage degradation appear in the public dashboard. Transparency can be an advantage of a small local operator, but only if it survives a tough day.

MyDC competes with three kinds of exit

MyDC is not simply competing with another Austrian virtual server price. Its customer can exit in three directions, each modifying the dependency model.

The first is a broader European cloud with an Austrian zone.Exoscalepublicly lists two zones in Vienna and a wider catalogue including virtual machines, Kubernetes, entity and block storage, private networking, databases and APIs. Such a platform may offer stronger automation and multi-zone patterns while introducing a larger service surface and a foreign contractual identity. For a team that needs managed data services or programmatic fleet control, this breadth may outweigh myDC's personal support. For one that wants a handful of conventional machines and a local relationship, it may add complexity without solving a pressing problem.

The second is a large commodity infrastructure provider in a neighbouring jurisdiction.Hetzner Cloudemphasises low-cost shared and dedicated virtual CPU options, an API, command-line tools, networks and integrations. It is a strong price and automation reference, but a German location is not an Austrian location. Comparing it with myDC reveals what the locality premium buys: not only milliseconds but also contractual proximity, a national data location claim and the possibility of partner-assisted operation.

The third is self-operation, often with the same open-source family. A customer can run Proxmox and backup software on owned or colocated hardware and keep deeper control over configuration and keys. It also inherits procurement, capacity planning, patching, monitoring, on-call, spare parts, power and facility coordination. MyDC's managed Proxmox Backup Service is interesting precisely because it can complement this path: keep primary control on-site while placing a managed copy elsewhere.

There are also Austrian managed service providers and facility operators who can assemble custom private clouds. They may offer more tailored accountability and less instant self-service. MyDC occupies a useful middle ground: more packaged and transparent than a custom integration project, more personal and geographically specific than a large cloud, and less operationally heavy than owning the entire stack.

No public evidence examined supports a market share claim or proves that myDC is cheaper overall. Its defensible differentiation is qualitative. It packages familiar infrastructure, Austrian guardianship and reachable specialists into a small catalogue. The risk is that the same compactness may mean fewer disclosed service levels, fewer automation interfaces and greater reliance on key people or partners. Procurement should decide which side of this trade-off matters for the workload rather than awarding points for company size in either direction.

Nine tests before calling the service sovereign

The word 'sovereign' is most useful as a test plan. A buyer considering myDC can turn the public evidence gaps into nine concrete acceptance tests.

1. Reconcile the identity and accountability map.Put myDC Cloud Services GmbH, the implementation partner, the facility operator, the network operator, software licensors and support subcontractors into a single table. For each, state the contract, task, data access and escalation duty. Confirm that the data processing agreement names the same entity as the order.

2. Obtain a location schedule.List the site and country for active disks, Ceph replicas, virtual-machine backups, Proxmox backup stores, dashboard data, logs, support attachments and disaster recovery copies. Record whether 'Austria' is a contractual condition, what exceptions exist, and how a location change is notified. A city name is not enough to assess common failure domains.

3. Demonstrate failure, not just redundancy.Ask myDC to show the architecture under appropriate confidentiality: number of compute nodes, storage replication policy, Ceph failure domains, monitor quorum, network paths, capacity margin and backup separation. Observe a host-failure drill and measure guest restart. Ask for the results of recent power-transfer and restore tests.

4. Convert availability language into a workload objective.Identify the exact service-level percentage, measurement point, exclusions, notification process and remedy for the purchased product. Define recovery-time and recovery-point objectives separately. Add application monitoring from an independent network. 'Up to 99.99%' should never be the last line of a production design.

5. Test the control plane.Enforce two-factor authentication, separate billing and technical roles, inspect account recovery, export administrative events, and learn how provider staff access. Determine whether an API or reproducible configuration method exists. Simulate loss of dashboard access and confirm an authenticated emergency change path.

6. Restore the largest realistic system.Perform file-level and full-machine restores. Measure verification time, data transfer throughput, application consistency and dependency recovery. Repeat after encrypting the backup, and prove that the customer can recover if myDC is unavailable. Document who holds the keys and what happens when the key holder leaves.

7. Assess stress, not just steady state.Model growth in storage, addresses, network, backup retention, DDoS defence and support. Apply the contract's energy and index adjustment logic. Add partner labour, parallel migration months and data export. Compare this total with an Austrian-zone cloud, a German commodity host and self-operated Proxmox.

8. Exercise exit while the service is healthy.Export a machine and a backup, rebuild its network elsewhere, update allowlists and DNS, and request secure deletion of the source. Confirm the notice dates for each product contract and the cost of early termination. Record which dashboard artefacts and logs remain available after closure.

9. Validate the assurance scope.Obtain the current facility certificate, exact scope, Cyber Trust level and validity, security contact process, penetration test evidence, subcontractor list and incident notification commitment. Map these controls to the customer's GDPR, NIS2 or DORA obligations rather than accepting a compliance shortcut from a partner page.

These tests are proportionate even for a small provider because most do not require public disclosure of sensitive diagrams. They require the buyer and operator to share a precise private understanding. MyDC's local scale could make this dialogue easier than with a global platform. If the company can answer quickly and test visibly, the opacity in marketing pages becomes less consequential. If it cannot, the locality claim carries more risk than it solves.

Watch the boundary, not the slogan

Five developments would materially change the assessment.

First, a public service schedule that associates each product with a defined availability target, measurement method, maintenance handling and response commitment would make the operational promise easier to assess. Second, publication of the facility certificate holder and scope—and a clear description of the sites that host production and backup data—would close the largest gap in the locality evidence. Third, a documented image and configuration export path, ideally with an API or reproducible tooling, would turn the open-source architecture into demonstrably low exit friction.

Fourth, myDC's security assurance could move from labels to a layered evidence pack: company controls, inherited facility controls, software configuration, partner access and customer duties. The Cyber Trust framework can be a useful step, but the exact level and registered scope matter. Fifth, the provider's incident communication should be observed over time. A status page with accessible incident reports and maintenance outcomes would allow buyers to verify how a small operator learns.

The company's scale also deserves neutral observation. New partners can extend implementation capacity; they can also widen the accountability chain. New managed services can increase revenue and customer convenience; they can also add upstream product lifecycles like Kopano's shutdown. New facilities or network paths can improve resilience; they can also complicate the promise that every copy stays within a understood boundary. None is inherently good or bad. Each modifies the guardianship.

MyDC's proposition is strongest when stripped of mystique. It is an Austrian GmbH offering configurable KVM and Ceph infrastructure, backup and selected managed services through a convenient dashboard and a regional support ecosystem. It can be an excellent alternative to a distant commodity host or an oversized public cloud account. It is not an escape from facilities, operators, software maintainers, contract deadlines or customer administration.

The correct conclusion is therefore conditional but useful. The public evidence proves the enterprise-brand bridge and supports a genuine Austrian operational footprint. It supports the presence of open-source virtualisation and distributed storage, a self-service workflow, local support and a serious attempt at resilience. It does not yet prove every failure domain, certificate scope, service level or exit step that a critical workload demands.

A local cloud promise is only as strong as its least visible transition. For myDataCenter.at, the opportunity is to make those transitions its product: named, contractually bounded, technically testable and humanly accountable. When locality becomes a chain of evidence rather than a country label, a small provider can offer something that larger clouds find surprisingly hard to match.