Take your design agent to production, and check what must be in place before your first real user. The executor, where CE.SDK, IMG.LY’s design engine, runs the code the model writes, is IMG.LY’s Docker image on your servers.
- Host the Executor — run the image on your container platform, hardened, with a new container for each conversation.
- Versions and Upgrades — keep the right versions equal, and upgrade and roll back without damaging a design.
- Security — see what the model’s code can reach, where each key lives, and what IMG.LY receives.
Before Production#
Each item below fails quietly when it is missing, which is why it is on this list. Check them once before the first real user, and again after each upgrade.
Versions and Designs#
- Versions are pinned and logged. The SDK, the executor image, and every
CE.SDK that saves designs (your editor, your jobs) run one exact version,
installed with
--save-exact, because an older CE.SDK silently drops what a newer one saved (see Versions and Upgrades). Your agent runner, the code of yours that runs the agent loop, logs(await codesign.handshake()).versions, so you can tell which build served a request. - Your design store passes its test. Run the storage test in Connect Your Storage. Your store and your editor’s save route both refuse a save from an older CE.SDK.
Billing and Spending#
- One charged export reached your account. Export one PNG in the environment you ship, and find its charge in your IMG.LY dashboard. It proves that the license key and the account are the ones you meant (see Billing).
- Your product shows a refused export. An
export_refusederror carries a message for the person, such as no credits left or a file over the limits. Show it, and an upgrade prompt if you sell one. - Spending is bounded. Your agent loop has a limit on steps and a spending cap per conversation, and users who can trigger exports have per-user limits (see What It Costs).
Tenants and Fonts#
- Tenants stay apart. A tenant is one customer account of yours. Each conversation id (the id your runner gives one chat or job) is unique across your tenants, because one executor serves one conversation and keeps what it loaded. Give each conversation that tenant’s design store and that tenant’s plugin options (the settings your engine plugins receive), with a short-lived token for the signed-in person (see Sign-In and Tenant Identity).
- Your brand fonts render. Render one design that uses each brand family, in every weight, and look at it. Two mistakes are silent: two sources that offer the same family name, and a weight you did not list. Both render another font with no error. A font file that fails to load is not silent: every edit, preview, and export names it (see Bring Your Brand).
The Executor#
- It runs hardened, with a new container for each conversation. Use the settings in Run the Image Hardened, which also covers Kubernetes.
- A used executor refuses a second conversation. Send a second
conversation to the first one’s executor: the call must reject with
executor_bound. Nothing else reports a container your platform reused. - Egress is closed. The executor reaches only the hosts it needs, and you tried a host it should not reach.
- Its secrets are stored and its port is private.
EXECUTOR_TOKEN, the secret your runner sends the executor, and your license key are in your platform’s secret store. The executor’s port is reachable only from your runner, so the token is not the only barrier.
Next Steps#
- Troubleshooting — find the cause when a container does not start or an export is refused.
- Bring Your Brand — list every family and weight your designs use.
- Connect Your Storage — put designs and files in the storage you already have.
- Add a Design Chat — pass each signed-in person’s tenant to the session.