Поширені запитання

Ні. Ваші інструменти пакуються як є; вашого коду ніхто не торкається. Пакування лише додає метадані: ідентифікатор пакета, версію, які випуски AutoCAD підтримуються та які команди реєструються.

Ні — радше швидше. Інструменти завантажуються під час першого виклику команди, а не на старті. До того ж **на шляху запуску AutoCAD не робиться жодного мережевого запиту**; це обовʼязкове правило цього продукту, а не оптимізація.

Працюватимуть далі. Встановлені інструменти живуть на комп'ютері інженера й не залежать від сервера. Поки він недоступний, чекають лише нові встановлення та оновлення.

Ні: установка на вашому сервері існує саме для цього. Продукт не звертається назовні, і перевірка ліцензії теж локальна: підписаний файл читається на місці, жодного сервера не питають. (Хмарній установці зв’язок, звісно, потрібен.)

2025, 2026 і 2027. У кожного випуску власний шар пристосування, тож нова версія AutoCAD не означає переписування всього іншого.

На вашому сервері — нікуди: архіви пакетів, список користувачів і журнал аудиту лишаються у вашій базі даних, ми не маємо до них доступу, і продукт нічого не надсилає назовні. Якщо оберете хмару, ті самі дані лежатимуть на сервері, яким керуємо ми, у власній базі даних. **Ваші файли креслень не потрапляють у систему в жодному з випадків.**

Пакети підписуються алгоритмом ECDSA, і підпис перевіряється **також на клієнті**. Закритий ключ підпису ніколи не лежить на сервері, тож той, хто захопить сервер, не зможе змінити пакет і підписати його заново. Список довірених відкритих ключів теж не приходить із сервера — якби приходив, увесь механізм не мав би сенсу.

Прямо: бути адміністратором означає мати право публікувати, і двох адміністраторів, які діють разом, не зупинить жоден механізм. Проти **одного** є необовʼязкове правило чотирьох очей: другий адміністратор погоджує публікацію, і той, хто подав запит, не може погодити власний. Понад це у вас є журнал аудиту, який неможливо видалити, і опубліковані версії, які неможливо змінити.

Ні. Вхід відбувається за одноразовим кодом, надісланим на електронну пошту користувача. Немає сховища паролів, яким треба керувати, і немає бази паролів, яка могла б витекти.

Сервер — зазвичай пів дня: майстер встановлення перевіряє базу даних, пошту та сховище, **справді їх випробовуючи** — жоден крок не закінчується словом «збережено». Справжній час іде на те, щоб розібрати й запакувати інструменти, які у вас уже є.

Підтримується. PostgreSQL і SQL Server — рівноцінні варіанти: той самий набір тестів виконується на обох серверах, тож жоден із них не є варіантом «там, напевно, теж працює».

Це вирішуєте ви. Автоматичну міграцію можна лишити ввімкненою або вимкнути й доручити вашому ІТ-відділу виконати сценарії міграції вручну; сценарії лежать у теці встановлення, готові для обох баз даних.

Поштою. Продукт записує збої з **номером кореляції**; ваш ІТ-відділ за ним знаходить повну подію в локальних журналах і може поділитися з нами відповідним діагностичним записом. Це прибирає майже весь обмін на кшталт «чи можете надіслати знімок екрана».

Нічого не зупиняється. Зі спливлою ліцензією користувачі так само входять, каталог так само завантажується, а встановлені інструменти працюють далі; система лише повідомляє адміністратора. Цю поведінку закріплено тестом у самому продукті.

Так, і пілот — це справжня установка: на вашому сервері, з кількома вашими інструментами та обмеженою групою інженерів. Пілоти не оплачуються.

За стандартною передплатою — ні. Для корпоративних покупців можна домовитися про депонування початкового коду. За умов, погоджених у такому договорі, це може дати доступ до коду й допомогти підтримувати установку робочою.

Хмарна установка готується, а її ціни надруковано на сторінці цін; облікові записи відкриваємо зі списку раннього доступу в міру можливостей. Якщо хочете почати сьогодні, установка на вашому сервері готова. Вона зʼявилася першою тому, що для більшості проєктних організацій тримати дані креслень та інструментів у себе — питання, яке не обговорюється.