# TeXise SaaS environment and deployment configuration TeXise remains local-first. These settings configure the trusted account/CMS/support/licensing service plus optional Pro execution services. Project files, PDFs, Paper Memory data, filesystem handles, local AI models, BYOK vendor keys, datasets and Git credentials are never SaaS database fields. Cloud Compile and Linux Terminal receive files only for an explicit server execution request. The production installer reads `/etc/texise/texise.env` and preserves existing administrator values on upgrade. `deploy/config/texise.env.example` is the canonical example. ## Core application ```dotenv TEXISE_PUBLIC_URL=https://www.texise.com TEXISE_SHOP=https://your-lifetime-shop-destination.example/ TEXISE_PRO_MONTHLY_SHOP=https://your-monthly-pro-shop-destination.example/ TEXISE_SAAS_ENABLED=1 SESSION_SECRET= TEXISE_SESSION_DAYS=30 ``` `TEXISE_PUBLIC_URL` is the canonical public origin. `TEXISE_SHOP` and `TEXISE_PRO_MONTHLY_SHOP` are the safe checkout destinations exposed by the public configuration API. `SESSION_SECRET` never reaches browser JavaScript. For Payhip licence verification, keep `PAYHIP_PRODUCT_SECRET_KEY` server-side and optionally set `PAYHIP_PRODUCT_LINK` to Payhip's short product token; it is separate from the public `TEXISE_SHOP` URL. `TEXISE_SAAS_ENABLED=1` is the clearest production activation flag. For upgrade safety, the default `MYSQL_DATABASE=texise_db` alone does **not** activate SaaS. ## MySQL ```dotenv MYSQL_HOST=127.0.0.1 MYSQL_PORT=3306 MYSQL_DATABASE=texise_db MYSQL_USER=texise MYSQL_PASSWORD= TEXISE_MYSQL_CREATE_DATABASE=0 ``` The normal least-privilege deployment uses an already-created database and `TEXISE_MYSQL_CREATE_DATABASE=0`. Set `TEXISE_MYSQL_CREATE_DATABASE=1` only when the configured MySQL account is intentionally allowed to run `CREATE DATABASE IF NOT EXISTS` during bootstrap. All application SQL values are parameterized. Dynamic identifiers are allowlisted/quoted only in the migration/bootstrap layer. ## Google OAuth ```dotenv GOOGLE_CLIENT_ID= GOOGLE_CLIENT_SECRET= ``` Both values are required together. The callback is derived from the canonical application URL: ```text ${TEXISE_PUBLIC_URL}/api/auth/google/callback ``` The secret remains server-side. The browser receives only the Google authorization redirect. TeXise uses authorization-code flow with state and PKCE and maps users by Google's stable `sub` identifier. ## SMTP / support ```dotenv SMTP_HOST=smtp.example.com SMTP_PORT=587 SMTP_USER= SMTP_PASSWORD= SMTP_FROM=support@texise.com SMTP_SECURE=0 ``` `SMTP_HOST`, `SMTP_PORT` and `SMTP_FROM` are the minimum tuple when SMTP is enabled. Set `SMTP_SECURE=1` for implicit TLS endpoints such as port 465 where appropriate. Contact tickets are committed to MySQL before SMTP is attempted. A mail failure therefore does not discard the support request. ## Existing trusted-server configuration Existing TeXise compiler/license/scholarly/AI-review settings remain supported. The installer must preserve `/etc/texise/texise.env`, `/etc/texise/config.json`, entitlement keys, license keys and other existing deployment secrets. ## Browser-safe public configuration `GET /api/config/public` exposes only: - whether SaaS is enabled; - whether Google login is enabled; - whether contact is enabled; - the safe public `TEXISE_SHOP` destination. It never exposes MySQL credentials, Google client secret, SMTP credentials, `SESSION_SECRET`, Payhip verification secrets or administrator API credentials. ## Upgrade-safe activation behavior SaaS is considered requested when one of these is true: - `TEXISE_SAAS_ENABLED=1`; - MySQL host/user/password configuration is present; - `TEXISE_MYSQL_CREATE_DATABASE=1`. `MYSQL_DATABASE=texise_db` by itself is intentionally ignored as an activation signal. This protects editor-only installations that receive the default database key during an upgrade. If SaaS is requested but MySQL or session configuration is incomplete, deployment fails before runtime activation. A partial Google or SMTP tuple also fails validation rather than silently starting a broken account service. ## Runtime dependencies The trusted server pins these production dependencies in `server/package.json`: - `mysql2` — MySQL pool and transactions; - `bcryptjs` — administrator password hashing and legacy-password upgrade; - `nodemailer` — SMTP support notification; - `ws` — existing collaboration signaling. For SaaS deployments the installer installs the pinned runtime dependencies into a staged trusted-server directory before activation. A failed dependency stage cannot overwrite the currently active trusted server. ## Font assets before build The downloadable source package intentionally does not redistribute font binaries. Before building, restore the project-owned font assets described in `FONT-ASSETS-REQUIRED.md`. This includes Inter Variable, JetBrains Mono Variable, Moranga Light/Regular/Regular Italic/Bold, STIX Two Text normal/italic, and any compiler font assets omitted from the delivery package. ## Production MySQL and administrator bootstrap The production default database is `texise_db`. Custom existing database names remain supported; the installer migrates only the historical TeXise-owned default `texisecom_db` to `texise_db` and preserves administrator-customized names. Provision the database separately with a least-privilege application account, then run `texise-saas preflight`. The preflight executes idempotent migrations and creates `admin@texise.com` only when it is absent. The initial bootstrap password is `admin` and `/admin/login` immediately requires a replacement of at least 12 characters. Recommended application privileges on the configured database are `SELECT, INSERT, UPDATE, DELETE, CREATE, ALTER, INDEX, REFERENCES`. `DROP` and global database-creation privilege are not required for normal operation. Leave `TEXISE_MYSQL_CREATE_DATABASE=0` when the database is provisioned by an administrator. Operational helpers installed by TeXise: ```bash texise-saas preflight texise-saas status texise-saas logs ``` `texise.service` is the loopback-only trusted API for accounts/sessions, licensing/quota, CMS/support, scholarly gateways, AI Review fallback, collaboration signaling and server-authoritative Pro execution brokerage. Local Compile remains browser-local; optional Cloud Compile and Linux Terminal are delegated to their private Docker services. ## Dedicated Pro execution images Cloud Compile · Pro and Linux Terminal · Pro use independent operator-controlled Docker images: ```dotenv TEXISE_CLOUD_COMPILE_IMAGE=texlive/texlive:latest TEXISE_CONSOLE_IMAGE=texlive/texlive-console:pro The canonical `texlive/texlive-console:pro` tag is built locally by TeXise from `deploy/docker/console/`; it is not expected to exist on Docker Hub. Only non-default operator-supplied Console image names are pulled as external images. ``` The images are intentionally separate. Cloud Compile starts `texlive/texlive:latest` non-interactively with networking disabled and shell escape disabled. Linux Terminal starts the TeXise-local `texlive/texlive-console:pro` image interactively with controlled outbound Docker networking for GitHub and scientific workflows. Either image can be pinned to an immutable digest after certification. ## Cloud Compile · Pro ```dotenv TEXISE_CLOUD_COMPILE_ENABLED=0 TEXISE_CLOUD_COMPILE_WORKER_URL=http://127.0.0.1:3001 TEXISE_CLOUD_COMPILE_WORKER_SECRET= TEXISE_CLOUD_COMPILE_ALLOWED_ENGINES=pdflatex,xelatex,lualatex ``` `texise.service` is the only browser-facing broker. The worker remains loopback-only. Enabling Cloud Compile causes deployment certification to compile test projects with every advertised engine and a bibliography probe before activation succeeds. ## Linux Terminal · Pro ```dotenv TEXISE_LINUX_TERMINAL_ENABLED=1 TEXISE_CONSOLE_GATEWAY_URL=http://127.0.0.1:8787 TEXISE_CONSOLE_GATEWAY_SECRET= TEXISE_CONSOLE_MAX_UPLOAD_BYTES=50000000 TEXISE_CONSOLE_MAX_DOWNLOAD_BYTES=100000000 TEXISE_CONSOLE_SESSION_MINUTES=240 ``` Linux Terminal requires `TEXISE_SAAS_ENABLED=1` because ownership and Pro entitlement are server-authoritative account properties. The browser never receives `TEXISE_CONSOLE_GATEWAY_SECRET`; it receives a one-time short-lived websocket credential after `/api/terminal/sessions` succeeds. Project transfer is explicit and session files are temporary. Linux Terminal certification is deployment-blocking for the complete advertised toolchain inside the locally built `texlive/texlive-console:pro`, including NumPy, SciPy, pandas, Matplotlib and SymPy. No host-side scientific Python overlay is provisioned or mounted.