Product Review: IONOS Data Center Designer (DCD)

IONOS Data Center Designer (DCD) is a visual, diagram-centric tool for building and managing Virtual Data Centers (VDCs).  Instead of writing infrastructure-as-code (IaC), users easily model servers, storage, networks, and policies by dragging elements from a palette into a workspace, configure them in an inspector pane, and then provision an explicit apply step to create a working environment.   The tool is aimed at cloud architects, SysAdmins, and DevOps teams that value the ease of use of visual design, clear governance, and step-by-step provisioning.  It’s particularly useful in regulated or multi-team environments  that must show intent and approvals, but equally helpful in other use cases thanks to its simplicity and ease of use.

Getting Started and Access

DCD is delivered as a web app and supports mainstream browsers (Chrome and Firefox are recommended).  Access DCD at https://dcd.ionos.com/latest/

The login screen supports German, English, Spanish, and French.  Organizations using IAM Federation can route users through their own Identity Provider (SSO) as part of the sign-in process.  Creating the first VDC is simple:  Name it, choose a region, add an optional description, and (optionally) attach a default network security group, so new VMs inherit baseline rules.  Users can start the create flow from the left navigation or the dashboard.

Access control is handled centrally.  Users grant Create Data Center privileges to any group to let its members create and manage VDCs.  They can also revoke it at the group or individual user level.  Within existing data centers, users typically need edit access to make changes, while Visible to Groups status only grants read access.

How the Product Works: The Modeling Experience

DCD’s UI is arranged around a palette, a workspace (canvas), a context menu, and an inspector pane.  Users drag elements (servers, storage, networks, etc.) into the workspace, right-click for actions, and set properties (name, availability zone, vCPU/RAM, images, SSH keys, cloud-init, security groups, and more) in the inspector. Elements can be joined (e.g., attaching storage to a server) and certain connections auto-snap when compatible.

The DCD PALETTE is the left-hand toolbox of building blocks users drag onto the canvas to model a virtual data center.  It’s organized by function and uses clear icons/labels, so you can grab a server, a network, or a storage volume and drop it into place; compatible items “snap” together (e.g., a volume onto a server), and the moment you select something, the inspector opens on the right for its settings. In short: the palette holds the parts, the canvas shows the topology, and the inspector handles configuration.

Typical palette groups include:

• Compute:  Dedicated Core servers, vCPU servers, or lightweight Cubes, size CPU/RAM, and pause/restart instances
• Storage:  Attachable volumes and related disk resources, like managing images/snapshots
• Networking:  LANs/VLANs, Internet/public connectivity elements, NICs, IP addressing
• Security & traffic control:  Firewall/rule elements and policy hooks
• Utilities/services:  Common connectors or service nodes used to complete an architecture

?The palette is visual, so users simply pick a part, drop it, connect it, then fine-tune in the inspector.  It’s fast to learn and hard to get lost.

The CANVAS is the live blueprint – in other words, the central workspace where users lay out and connect all the pieces of their VDCs.  Users drag elements from the palette onto this surface, arrange them into tiers (web/app/db), and create relationships (e.g., attach storage to a server, connect a server NIC to a LAN or the Internet).  Clicking any object opens its settings in the inspector pane on the right, and right-clicking opens a context menu for common actions.  The canvas is what makes the topology obvious at a glance and allows users to see what talks to what, and through which network.

In practice, users use the canvas to sketch, reason, and then apply.  Users can go through as many iterations as necessary until their VDC looks right, and nothing changes in their account until they hit PROVISION CHANGES, so the canvas doubles as safe design space and living documentation of the environment that’s about to be deployed.

The INSPECTOR PANE is the right-hand panel that opens whenever users select something on the canvas.  It’s also  context-aware.  So, for instance, a server would shot compute and image fields (name, availability zone, vCPU/RAM sizing, OS image, optional cloud-init, SSH keys); storage might show size/performance/image options; and networking objects expose NIC/LAN details (LAN selection, firewall toggle/rules, network security groups, IPv4 via DHCP or a reserved IP).  Think of the inspector pane as the “properties sheet,” where users fine-tune whatever they just dropped or clicked.

As with the context menu, edits made in the inspector pane are staged, so users will see them reflected on the canvas immediately, but nothing is actually created or changed in their account until they select PROVISION CHANGES.  The inspector also surfaces validation hints (e.g., missing image or IP), so users can fix issues before applying. 

In short, think of the three main parts of DCD this way:   Palette = parts, Canvas = layout, Inspector = configuration.

The CONTEXT MENU offers another way to make changes to items on the canvas.  It’s a quick-action layer that allows users to change options for any individual elements, and provides quick access to many of the common management and configuration options, so users don’t always have to search for them in the inspector pane.  It could be very useful when making limited changes to items on the canvas.  It’s context-aware, so the options change based on what’s clicked.  As with other changes, actions are staged as design changes and nothing is actually created or modified in the account until PROVISION CHANGES is clicked.

What It’s Like to Use DCD

DCD offers a wide range of value and benefits for users that simplify their day-to-day data center design experience. 

Because the canvas doubles as living documentation, and the provisioning gate keeps changes deliberate, DCD provides clarity and speed for complex topologies.  With ops-friendly controls without having to leave the canvas, the inspector pane makes it easy to perform necessary actions on visual objects (e.g., attaching volumes, associating SSH keys, setting cloud-init, assigning IPs, and toggling firewall/NSG behavior).  Governance is baked into the platform through the combination of group-level privileges and role distinctions in each VDC, supporting separation of duties on larger teams.  Change safety and auditability provide protection against accidental, unnecessary, or unapproved changes.  This is particularly important in shared or production-adjacent environments.

Key Strengths:

• Diagram-first clarity:  The palette/workspace/inspector model makes infrastructure self-explanatory.
• Full-stack coverage from one UI:  Compute, storage, IPs/LANs/firewalls, images/snapshots, SSH keys, cloud-init, and console access are unified.
• Governed provisioning:  The explicit PROVISION CHANGES step allows users to review a validation summary, resolve conflicts (if needed), authenticate, then provision – reducing accidental changes and making changes auditable.
• Enterprise-friendly access control:  Granular privileges for who can create/manage VDCs and read-only visibility for stakeholders.
• Low cognitive load for networking:  Public vs. private LANs, NICs, DHCP, and reserved IPs are modeled cleanly and configured in the same place.

DCD is a great fit for teams that present or review infrastructure visually (architecture boards, change advisory, compliance), SMBs and enterprises transitioning from on-premises diagrams to cloud topologies, and ops teams that value deliberate provisioning and clearly scoped permissions.  That’s a very large potential user group.

In fairness, DCD might be less ideal for highly automated platform teams where everything is Git-driven, but even then, those teams can benefit from DCD for design reviews and ad-hoc modeling.

A Step-by-Step Guide to Creating or Modifying a Data Center in DCD

Before You Start (One-time setup)

• Sign in to DCD:  Open a browser and go to dcd.ionos.com.  Choose your language, enter your account email, then your password (and TOTP if 2FA is enabled).  If your org uses IAM Federation, you’ll be redirected to your IdP.  Once in, you’ll see the top menu, left nav, and the dashboard.
• Check permissions (if you’re in a team):  Members of a group need the Create Data Center privilege to create/manage VDCs; admins/owners have it by default.  To grant permission, navigate to Menu → Management → Users & Groups → Groups → (select group) → Privileges tab → Create Data Center.  View-only users added to a VDC with Visible to Groups can see but not change it.

Create a New Data Center (VDC)

• Start the create flow:  From the left navigation:  Virtual Data Centers → Create new, or from the Dashboard: My Virtual Data Centers → Create new.
• Fill in the basics:  Name (unique), region (physical location), optional (but recommended for clarity) description.  Create default network security group, so new VMs inherit baseline rules.  Click Create.  Your new VDC appears on the Dashboard and can be opened in the canvas workspace.
• Open the VDC canvas.  You’ll work visually with the palette (left), workspace (center), and Inspector (right).
• Add a server:  Drag a Dedicated Core server (or your preferred server type) from the palette to the workspace.  In the Inspector → Settings, set Name, Availability Zone, CPU architecture, Cores, RAM, and attach Network Security Groups (optional).
• Attach storage (boot volume/image):  Drag a Storage element onto the server to snap them together.  Set Name, Availability Zone, Size (GB), Performance (Standard/Premium), Image (IONOS or your own), and a password for the OS image, if needed.
• Give it network connectivity:  Click the server’s “+” to add a NIC, then attach it to the Internet element for public access, or keep it on a private LAN.  In the Inspector → Network, review LAN (public vs. private), Firewall (disabled by default, enable and set rules as needed), Network Security Groups, IPv4 (DHCP by default, but you can assign a reserved IP manually).
• (Optional) Create a private LAN:  Double-click the server’s “+” to create a NIC attached to a private LAN.  Name (and color) the LAN in the Inspector.  Use this for east-west traffic (e.g., app↔db).
• Provision your design:  Click PROVISION CHANGES in the Inspector.  Review the Validation summary, enter your password to confirm (conflicts can be resolved without password), then Provision Now.  Wait for the Provisioning Complete message.
• Result:  You now have a running VDC with compute, storage, and networking set up.  From here, you can continue adding servers, load balancers, gateways, etc., using the same canvas and Inspector.

Modify an Existing Data Center

• Open the VDC:  From the Dashboard, click the VDC under My Virtual Data Centers.  Make sure you have Edit access (remember, view only groups can’t change resources).
• Change servers:  Select a server on the canvas → Inspector → Settings to adjust vCPU/RAM, availability zone, or update network security groups.  To add/resize storage, drag a Storage element on, or select an existing volume in the Inspector and adjust Size/Performance/Image parameters.
• Update networking:  Add or edit NICs, flip a NIC to a public LAN (attach to Internet), or keep it on a private LAN.  Configure Firewall (reminder, it’s off by default, so enable and set rules, if needed), Network Security Groups, or change IP assignment.
• Apply the changes safely:  Click PROVISION CHANGES → review the Validation tab → enter password → Provision Now.  This apply step is required for any changes to take effect.

Handy Tips & Guardrails

• Naming & regions:  Choose clear names and the correct region at creation.  Region can affect quotas/limits and latency.
• Baseline security:  Enabling a default network security group at creation gives every new VM a safe starting posture.  Refine security with per-NIC firewall rules.
• Privileges:  If a teammate can’t create or edit, verify their group has Create Data Center (for creation) and that they have Edit access on the specific VDC.
• DHCP vs. manual IPs:  DHCP is easy for most cases.  If you run your own DHCP server, uncheck DCD’s DHCP, so it won’t reassign your IPs.  Use reserved IPs for stable addressing.

The Verdict

IONOS Data Center Designer is a well-executed visual builder for cloud infrastructure.  It makes topology obvious, ties configuration to a single canvas, and treats provisioning as a reviewable event.  If your team benefits from visual modeling and wants governance and clarity without giving up low-level controls, DCD is an easy recommendation.  If you’re a code-only shop, keep it in your toolbox for planning and stakeholder communication, even if your pipeline remains IaC-first.  While DCD may not replace IaC in those cases, it complements those pipelines effectively for design, reviews, and targeted edits.

IONOS Data Center Designer makes cloud architecture feel approachable.  The drag-and-drop canvas, clear inspector pane, and “provision changes” review turn complex topologies into something users can sketch, reason, and apply with confidence.  New users can stand up a working VDC in minutes, while experienced operators keep fine-grained control over images, keys, IPs, and firewall rules, all from a single, consistent UI.

Beyond speed, DCD adds durable value to team workflows.  Visual models double as living documentation, access and privileges enforce clean separation of duties, and the validation gate creates an auditable trail for every change.  The net result is fewer surprises, faster iteration, and a shared understanding of “what’s running where,” which is exactly what most teams need.