Frequently Asked Questions

Here are the answers to some frequently asked questions. If you can't find what you're looking for, please feel free to e-mail us at

I've signed up for an account but I didn't receive a verification e-mail

In many cases where the verification e-mail isn't received, the e-mail is blocked by a spam filter. If you've checked your spam/junk folders and still can't find it, please e-mail us at and we'll look into it for you.

How do I create and edit diagrams?

Structurizr is not a conventional diagramming tool where you create boxes on a canvas. Instead, you need to create a software architecture model using code and upload it to Structurizr via the web API. Alternatively, you can create diagrams with text using Structurizr Express.

See About Structurizr for more details.

Can I encrypt my data before sending it to you?

Yes, customers on a paid plan can use client-side encryption.

Do I really have to send my software architecture model to you?

No, you can use the on-premises installation.

But what if I'm not allowed to use cloud services?

We also have a standalone on-premises installation that you can license for local installation.

What happens to my workspaces when my paid plan expires?

Users on the Free Plan can create three workspaces so, when your paid plan expires, the three workspaces that you created first will be retained as-is. The other, more recent, workspaces will be retained too, but marked as read-only, signified by the following label on your dashboard: Read-Only

You can still view the diagrams and read the workspace via the web API, but no changes can be made. To make changes to these workspaces, you can either upgrade to a paid plan or get the content (e.g. via the API) and re-upload it to one of your active workspaces. Any paid features features you were using (e.g. shapes) will no longer work.

My diagram doesn't fit on one page; what should I do?

Even with a relatively small software system, it's tempting to try and include the entire story on a single diagram. For example, if you have a web application, it seems logical to create a single component diagram that shows all of the components that make up that web application. Unless your software system really is that small, you're likely to run out of room on the diagram canvas or find it difficult to discover a layout that isn't cluttered by a myriad of overlapping lines. Using a larger diagram canvas can sometimes help, but large diagrams are usually hard to interpret and comprehend because the cognitive load is too high. And if nobody understands the diagram, nobody is going to look at it.

Instead, don't be afraid to split that single complex diagram into a larger number of simpler diagrams, each with a specific focus around a business area, functional area, functional grouping, bounded context, use case, user interaction, feature set, etc. The key is to ensure that each of the separate diagrams tells a different part of the same overall story, at the same level of abstraction.