Frequently asked questions

No. Your tools are packaged as they are; your code is not touched. Packaging only adds metadata: the package identity, its version, which AutoCAD releases it supports and which commands it registers.

No — if anything, faster. Tools load when you first call a command, not at startup. On top of that, **no network request is ever made on the AutoCAD startup path**; that is a binding rule in this product, not an optimisation.

They keep working. Installed tools live on the engineer’s machine and do not depend on the server. While it is unreachable, only new installations and updates have to wait.

It is not — the on-premises installation exists for exactly this. The product never connects outward, and licence verification is offline as well: a signed file is read locally, nothing is asked of any server. (The cloud installation, naturally, needs a connection.)

2025, 2026 and 2027. Each release has its own adapter layer, so a new AutoCAD version does not mean rewriting everything else.

On-premises, nowhere: package archives, the user list and the audit trail stay in your database, we have no access to them, and the product sends nothing out. If you choose the cloud, that same data sits on a server we operate, in a database of your own. **Your drawing files never enter the system either way.**

Packages are signed with ECDSA and the signature is verified **on the client** as well. The signing private key is never on the server, so whoever takes over the server cannot alter a package and re-sign it. The list of trusted public keys does not come from the server either — if it did, the whole mechanism would be pointless.

Plainly: being an administrator means being able to publish, and two administrators working together cannot be stopped by any mechanism. Against a **single** one there is the optional four-eyes rule: a second administrator approves the release and the requester cannot approve their own request. Beyond that you have an audit trail that cannot be deleted and published versions that cannot be altered.

No. Sign-in uses a one-time code sent to the user’s email address. There is no password pool to manage and no password database to leak.

The server is usually half a day: the setup wizard verifies the database, email and storage settings by **actually trying them** — no step ends with the word “saved”. The real time goes into classifying and packaging the tools you already have.

Supported. PostgreSQL and SQL Server are both first-class supported options: the same test suite runs against both servers, so neither is the “it probably works there too” option.

That is your call. Automatic migration can stay on, or you can turn it off and have your IT team run the migration scripts by hand; the scripts ship inside the installation folder, ready for both database engines.

By email. The product records failures with a **correlation number**; your IT team uses it to find the complete event in the local logs and can share the relevant diagnostic record with us. That removes most of the “could you send a screenshot” traffic.

Nothing stops. With an expired licence users still sign in, the catalogue still loads and installed tools keep working; the system only tells the administrator. That behaviour is pinned by a test in the product.

Yes, and a pilot is a real installation: on your server, with a few of your own tools and a limited group of engineers. Pilots are not charged.

Not with a standard subscription. For enterprise buyers, source code escrow can be arranged. Under the trigger conditions agreed in the escrow contract, it can provide access to the source and help keep the installation maintainable.

The cloud installation is being prepared and its prices are printed on the pricing page; we open accounts from the early-access list as capacity allows. If you want to start today, the on-premises installation is ready. That one came first because keeping drawing and tool data inside the company is not negotiable for most engineering firms.