Running it on your own server

The product runs on your server, and that is not an option: it is the default. This page answers a single question — if you draw a line around your network, what crosses it?

What crosses the line?

“Your data never leaves” is a sentence you can only believe. The two columns below can be counted: on the left what stays on your server, on the right everything that reaches us.

Stays on your server

  • Your tool archives: LISP source, .NET assemblies, VBA files
  • Your engineers, and their e-mail addresses
  • The catalogue: which team sees which tool
  • The audit log: who published what, and when
  • The signing key — generated on your own machine during setup

Crosses the line

  • Your licence file: sent to you once, and read offline from then on
  • New releases of the product itself, when you decide to download them

Both entries on the right are movements you start. The product reports nothing to us on its own: no usage data is collected, and there is no remote kill switch. Even licence verification is a signed file being read; no server is asked.

What you take on in return

Running it yourself has a price, and we write that down too: the server is yours, so operating it is yours as well.

  • Setup day. The first run is a wizard in your browser, and at every step it measures what it claims: it really connects to the database, the test message really arrives, it really writes to the repository folder and deletes again. It does not say “saved”, it says “done”.
  • Backups. What has to be backed up is one database and one folder; the product keeps its data nowhere else.
  • Upgrades. The product installs as a service that starts with the machine. When you move to a new release is your decision.

If you would rather not carry those three, the cloud installation exists for exactly that: its prices are published, and so is the fact that it is still being prepared. What the product protects — and what it cannot protect — is written down separately.

This is not a trimmed-down edition

In most products the on-premise build is whatever is left of the cloud one. Here it is the other way round: on-premise is the default, and the cloud is a setting.

  • The same binary, the same code, the same database migrations. A single setting decides the form of the installation.
  • No feature is withheld from the on-premise installation. If one were, on-premise would turn into a branch that nobody runs and nobody tests.
  • Installed tools already work independently of the server: while yours is down your engineers keep drawing, and only new installations and updates have to wait.

Let us see it on your server

Tell us your seat count and your AutoCAD versions, and we will come back with what the installation looks like in your environment and a firm annual figure.

Ask for a quote