Build React experiences with an isolated production runner.

Scope and limitations

Codable 1.0.0 is an AI-assisted React and Vite frontend builder. A signed-in user can describe a site, review streamed progress, inspect a secure preview, collaborate, retain revision history, download source or a verified production build, and publish static output to a stable path on the Codable installation.

Generated output still requires human review for correctness, accessibility, privacy, legal compliance, intellectual-property rights, and production suitability. Provider availability and output quality are outside the application author's control.

Compatibility and system requirements

Before purchase or deployment, ask the host to confirm long-running queue workers, one-minute cron, HTTPS, writable private storage, and outbound HTTPS access. Browser or host behavior outside this baseline should be evaluated in a staging installation.

Shared hosting versus a runner VPS

Codable separates the web application from untrusted build work. This is a security boundary, not an optional performance mode.

Installation

Prepare before uploading

1. Create a new, empty MySQL or MariaDB database and a least-privilege database user.
2. Prepare two different HTTPS origins, for example https://app.example.com and https://preview.example.com. Point both document roots to the same application/public directory, and keep every other application directory outside the public document root.
3. Issue and verify a valid certificate for both origins. The preview origin is a mandatory isolation boundary; do not replace it with an application path, wildcard cookie domain, or iframe exception.
4. Prepare working encrypted SMTP credentials and the separate runner described in Topic 05.
5. Keep the private Envato purchase record for the authentic package. The V1 installer does not request or transmit a purchase code.
6. Create a full hosting backup or use a clean staging account.

Upload and permissions

1. Upload the contents of the package's application/ directory to the private application directory. Dependencies are included in the prepared release; Composer and npm are not runtime requirements on shared hosting.
2. Confirm both origins serve only application/public. A request must never expose .env, storage, vendor, source code, or backups.
3. Allow the PHP user to write storage/, bootstrap/cache/, and the application root during installation. Do not use world-writable permissions.
4. Open https://app.example.com/install. The preflight verifies PHP, extensions, limits, writable paths, database, SMTP, HTTPS, and the runner.
5. Enter the canonical application origin and the distinct preview origin, plus company/contact details, database, first administrator, SMTP, and runner values. Submit once and wait for the real runner sample build to finish.
6. After success, remove any temporary installer environment values, confirm the installer is locked, start the queue worker, configure cron, and open Admin → System Health.
7. Verify https://preview.example.com/login returns 404, while a signed preview URL loads its nested JavaScript and CSS correctly. The preview host permits only read-only preview/publication paths.

CLI alternative

From the application directory, run php artisan core:install. It prompts for required values, including --url=https://app.example.com and --preview-url=https://preview.example.com. For automation, non-secret options are available; secret inputs use temporary process environment variables so they do not enter shell history:

CORE_INSTALL_DATABASE_PASSWORD
CORE_INSTALL_ADMIN_PASSWORD
CORE_INSTALL_MAIL_PASSWORD
CORE_INSTALL_RUNNER_SECRET_BASE64
CORE_INSTALL_RUNNER_VERIFICATION_KEYS_JSON

Unset those variables immediately after the command. Never place them in documentation, tickets, screenshots, command history, or a repository.

Editable source and safe customization

The main package includes editable Laravel and Blade source, themes, application/resources/ts, application/resources/css, application/resources/js, and the locked package.json, package-lock.json, Vite, TypeScript, and ESLint configuration. The runner likewise includes its TypeScript source, lockfile, configuration, and compiled runtime. A separate source archive is therefore unnecessary.

cd application
npm ci --ignore-scripts
npm run build

Build custom frontend changes in a private development or staging environment using the documented exact Node/npm toolchain, review the resulting public/build assets, and deploy them with the corresponding source. Do not expose source files through the web root, commit node_modules, edit generated vendor files, or expect support to cover custom modifications. Preserve license notices and rerun the security, type-check, build, and smoke gates after every customization.

Runner setup

The runner belongs on a dedicated Linux VPS or VM under an unprivileged service account. It accepts authenticated build jobs from the control plane, executes them inside resource-limited rootless Podman containers, and signs returned artifacts. It is not a public developer API.

1. Install rootless Podman 4.9 or newer and the exact Node.js 22.22.0 / npm 10.9.4 toolchain. Enable cgroup enforcement and lingering for the unprivileged service account. Budget at least 512 MiB of enforced memory per concurrent build, plus runner and operating-system overhead.
2. Copy the package's runner/ directory to a private path such as /opt/codable-runner.
3. Follow runner/README.md to install the locked toolchain, build the image, create /var/lib/codable-runner and /etc/codable-runner, and instantiate the supplied example configuration.
4. Generate unique HMAC and artifact-signing material on the server. Restrict secret/private-key files to the runner account (0400 or 0600). Transfer only the required identifier, HMAC secret, and verification public keys to the installer over a secure channel.
5. Install the supplied systemd unit, place a private TLS reverse proxy or equivalent authenticated network boundary in front of it, and restrict ingress to the control plane.
6. Run the runner's release gate without skipping Podman, then run its SBOM command. Resolve every failure before installation.

cd /opt/codable-runner
npm ci --ignore-scripts
npm run check
npm run image:build
npm run release:gate
npm run sbom

Exact configuration fields, rotation procedure, service unit, health checks, resource limits, and failure recovery live in runner/README.md and runner/SECURITY.md. Use those shipped files as the operational source of truth.

Queue worker

A persistent queue worker is mandatory. Configure Supervisor, systemd, or the hosting control panel's process monitor to keep this exact release queue set running from the application directory:

php artisan queue:work --queue=codable-agent,webhooks,exports,default --sleep=1 --tries=3 --timeout=3600

• Run it as the same restricted user that owns the application writable paths.
• Restart it after deployment or an update so it loads the new code.
• Do not use sync or null as the production queue connection.
• Check failed jobs and application logs before retrying. Repeated retry without fixing the cause can consume provider credits.

Cron and scheduler

Add one cron entry that runs every minute from the application directory:

* * * * * cd /absolute/path/to/application && php artisan schedule:run >/dev/null 2>&1

The scheduler drives the system heartbeat, stale AI-run recovery, due account deletion, privacy-export cleanup, attachment cleanup, and release-artifact cleanup. A five-minute cron interval is not equivalent. Confirm the heartbeat becomes fresh in Admin → System Health.

HTTPS and reverse-proxy configuration

• Use valid production certificates and set APP_URL and CODABLE_PREVIEW_ORIGIN to two different root HTTPS origins with no path suffix.
• Point both origins to the same public/ directory. Keep SESSION_DOMAIN=null so application cookies remain host-only and are never sent to the preview origin.
• Redirect HTTP to HTTPS at the edge. Keep secure, encrypted cookies enabled.
• If a load balancer, CDN, or proxy terminates TLS, set TRUSTED_PROXIES to explicit trusted addresses or networks. Do not trust every sender.
• Allow streaming responses and disable proxy buffering for the authenticated AI event stream where the proxy supports route-specific settings.
• Preserve Host and forwarded-protocol headers. Test sign-in, CSRF-protected actions, invitation links, signed preview links, nested preview assets, publishing, and the preview-host 404 boundary after a proxy change.

Database

The fresh installer accepts MySQL 8.4 LTS, MariaDB 10.11 LTS, or MariaDB 11.4 LTS. The target database must already exist, be empty, and use utf8mb4. The install-time user needs SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, REFERENCES, INDEX, and ALTER privileges.

Restrict database ingress to the application host, use a unique password, and do not share an administrative database account. The database stores identities, workspaces, projects, revision metadata, credits, jobs, audit records, and application configuration; include it in every coordinated backup.

Mail

Production requires authenticated encrypted SMTP: smtp with STARTTLS or smtps. The installer performs a real send test. Configure a verified From address and make sure SPF, DKIM, and DMARC align with the sending domain.

Email is used for account verification, password recovery, workspace invitations, and operational communication. A log mailer or an SMTP service that merely accepts but never delivers mail is not a production configuration. After changing mail settings, test delivery to an external mailbox and inspect the spam folder and mail-provider logs.

Storage and permissions

Keep private storage outside the public web root. The PHP/worker account needs controlled read/write access to storage/ and bootstrap/cache/. The application probes actual create/write/delete behavior during installation; directory labels alone are not sufficient.

• Prompt attachments, source archives, production artifacts, and privacy exports are private files delivered through authorized, expiring downloads.
• Default source-export retention is 24 hours and default build-artifact retention is 168 hours; the scheduled cleanup must run.
• Monitor capacity. The preflight requires at least 512 MiB free, but real capacity depends on active projects, revisions, and export volume.
• Never serve storage directly, and never upload a backup archive beneath public/.

First administrator run

1. Sign in using the administrator created by the installer, verify the email address, and enable the strongest account security offered by the installation.
2. Open Admin → System Health. Confirm database, cache, queue heartbeat, scheduler, storage, mail, runner, outbound webhooks, and production settings are healthy.
3. Review legal company details and public support/privacy/refund contacts. The included page text is a template, not legal advice.
4. Configure and test at least one AI provider, then review the included free plan and credit costs before inviting users.
5. Create a non-admin test user and exercise one complete project: prompt, stream, build, preview, export, publish, unpublish, and cleanup.
6. Review content pages, email templates, support-ticket handling, themes, and audit records before launch.

AI providers

The 1.0.0 admin registry exposes OpenAI, Google AI Studio, and Cloudflare AI. You need your own compatible provider account, API credential, service access, and billing arrangement. Provider fees are not included with Codable or the Envato license.

1. Open Admin → AI Providers and choose a provider.
2. Enter its write-only credential and any required account details, select a model available to your provider account, and save.
3. Run the built-in test. Do not enable a provider that fails authentication or model access.
4. Set priority if several providers are enabled. Monitor failures and cooldown state.

Credentials are encrypted at rest and are not returned to the browser after storage. Rotate a credential in the provider console first, replace it in Codable, test it, then revoke the old credential. Do not paste credentials into prompts or support tickets.

Models, provider cost, and application credits

Model catalogues, names, availability, quotas, safety behavior, context limits, and pricing are controlled by each provider and can change independently. Select only a model confirmed by the provider account and perform a real build test after changing it.

Codable tracks usage in an integer milli-credit ledger. The included plan and action costs are administrative usage controls, not money and not a promise of a fixed amount of provider compute. Owners should review the configured allowance and generation/build/image costs in the admin UI before launch. Users see the current balance and ledger entries.

Plans

Codable 1.0.0 ships with one included free plan. It controls access and credits without charging the user. The owner can review the plan and ledger from the admin area, but this release does not enable buyer-facing paid plans, checkout, recurring billing, or plan purchase.

Payment gateways

Payment webhook URLs

Payment sandbox-to-live workflow

Not applicable. There is no release-enabled gateway, payment sandbox, checkout, or live payment mode in Codable 1.0.0. AI-provider test and production credentials remain the installation owner's separate responsibility and are not a payment-gateway workflow.

Customer and subscription lifecycle

Not applicable to payment operations. Users receive access through the included free plan; the product does not create paying customers, subscriptions, renewals, invoices, payment refunds, or payment-provider cancellations. Account access, project membership, credit usage, privacy export, and account deletion are documented separately.

User management

Administrators can review users and account status. Users can register where registration is enabled, verify email, recover a password, manage account security, request a privacy export, and schedule account deletion. Workspace roles control project access; administrator access is separate and should be granted sparingly.

Do not share user accounts. Use the member and invitation workflow, remove access when a person leaves, review audit history, and avoid editing identity or membership records directly in the database.

Workspaces

A workspace is the tenant boundary for members, projects, knowledge, and access. Owners can invite members using expiring invitations, manage membership, and transfer ownership through the supported UI. A project's members and workspace access determine who may view or change it.

• Store reusable product context in workspace knowledge; keep project-specific facts in project knowledge.
• Review membership before sharing a preview or publishing.
• Complete ownership transfer before removing the previous owner.
• Do not treat invitation links as permanent credentials; revoke or replace unexpected invitations.

Projects

Create a project inside a workspace and supply a clear name and goal. Projects can be favorited, duplicated, configured, archived and unarchived, moved to trash, restored, or permanently purged through authorized actions. Use archive for inactive work and trash for a reversible removal; purge is the permanent operation.

Project settings, membership, knowledge, AI runs, revisions, exports, and deployments remain scoped to that project. Before destructive cleanup, download anything that must be retained and confirm no published revision or collaborator depends on it.

Builder workflow

1. Describe one concrete outcome, audience, content hierarchy, and visual direction. Never include credentials, regulated data, or private customer data in a prompt.
2. If needed, attach up to four sanitized JPEG, PNG, or WebP references within the installation's configured size limits.
3. Answer any clarification request, then watch the streamed run timeline. A run can be cancelled; interrupted streams can recover their recorded event state.
4. Review the preview. Use Select, Text, Draw, and Comment context to point at a precise change, then submit the next instruction.
5. Codable asks the remote runner to type-check and build the generated React/Vite files. Only a verified result becomes a usable revision.

Browser completion notices work while the relevant browser context is open; they are not push notifications after every browser tab is closed. AI output is non-deterministic—review every revision and do not promise that one prompt will produce a finished production site.

Revision history

Successful work creates an immutable revision record. Open history to preview or bookmark a revision. Restoring creates a new current revision from the selected state; it does not delete the revisions that came later. This preserves an auditable sequence.

Restore and deployment rollback are different: restore changes the builder's current project state, while deployment rollback changes the public revision. A restore does not silently move a live deployment.

Source export and production-build download

Source export produces a sanitized React project with lock metadata, instructions, and attribution for permitted use outside Codable. Production build produces verified static output from the isolated runner. Both are authorized, expiring private downloads; the UI displays artifact state and SHA-256 information.

• Verify the displayed hash after moving an artifact through an untrusted channel.
• Store long-lived copies outside the temporary application download area.
• Review dependencies, licenses, content, environment assumptions, and security before independent deployment.
• A generated build is frontend static output; it does not add a generated backend or database.

Publishing

Publish promotes a verified revision to a stable path on the Codable origin, under /p/{project-slug}. The release does not claim per-project subdomains. Deployment history records the published revision; rollback promotes a previous verified deployment; unpublish removes public availability.

Before publishing, verify navigation, mobile layout, accessibility, links, image rights, privacy text, and any external forms or services used by the generated frontend. Publishing is not legal or security approval.

GitHub, Vercel, and external connectors

GitHub, Vercel, Supabase, and similar deployment or backend connectors are not enabled or advertised in Codable 1.0.0. Use the supported source export or production-build download and follow the destination platform's own secure deployment process.

Public API

Codable 1.0.0 does not provide a supported public developer API or personal API tokens. Browser actions use an authenticated, CSRF-protected session interface; its internal routes are not a versioned integration contract. Do not automate them or expose them as an API.

Outbound webhooks

Workspace owners and administrators can manage outbound endpoints in Workspace Settings → Webhooks. Register a public HTTPS URL, select one or more supported events, and store the signing secret returned at creation. The secret is encrypted at rest and shown only at creation or rotation; rotating it invalidates the previous value immediately.

Every request uses Content-Type: application/json and a canonical version-1 envelope with id, type, version, occurred_at, workspace_id, and event-specific data. A test delivery is available from the endpoint screen but is not a selectable product-event subscription. Download the machine-readable version-1 contract for the exact envelope, event catalog, field types, transport headers, signature input, and retry defaults.

Verify the exact request

1. Read X-Webhook-Id, X-Webhook-Timestamp, and X-Webhook-Signature before parsing the body.
2. Reject stale timestamps according to your receiver policy and deduplicate by the event ID.
3. Compute HMAC-SHA256 over {timestamp}.{event-id}.{raw-body} with the endpoint secret and prefix the lowercase hexadecimal result with v1=.
4. Compare signatures in constant time, then parse the JSON and require the documented event version. Return a 2xx response only after durable acceptance.

Deliveries run on the dedicated webhooks queue. The default policy makes at most eight bounded attempts with exponential backoff and jitter. The delivery screen shows success, retry, and dead-letter state without exposing payloads or secrets; an owner or administrator may replay a terminal delivery. Repeated terminal failures can automatically disable the endpoint.

Localization and RTL

The V1 product interface and supplied documentation are English and left-to-right only. Arabic, RTL, language switching, and a complete translation workflow are not release claims. Codable keeps its web, CLI, queue, database-session, and persistence clock fixed to UTC. Site and user timezone preferences affect display through codable.display_timezone only; they do not mutate the operational clock and are not UI localization.

Backup and restore

Create coordinated encrypted backups of the database, private storage, application .env, application key, runner configuration, HMAC material, and artifact-verification keys. Keep backups outside the application host and public web root with restricted access and documented retention.

1. Place the application in maintenance mode or stop writes and queue workers.
2. Capture database and files from the same recovery point.
3. Restore into an isolated environment with the original encryption keys; mismatched APP_KEY makes encrypted state unreadable.
4. Validate permissions, database connectivity, storage, mail, runner trust, queue, scheduler, login, and one test build before reopening traffic.
5. Perform documented restore drills. An untested backup is not a recovery plan.

Update and rollback

1. Obtain a complete future package through the legitimate Envato item channel and verify its published identity and checksum.
2. Read that version's changelog and migration instructions before touching production.
3. Take and test a complete backup, then rehearse the documented replacement on an isolated staging installation.
4. Use maintenance mode, deploy the complete matching application and runner release, run only its documented migration steps, and never mix files from different versions.
5. Restart persistent queue workers and run the full login, build, webhook, export, publish, mail, scheduler, and health smoke test before reopening traffic.

Version 1.0.0 is the initial release, so it does not claim a tested upgrade path from an earlier Codable version. Use the fresh-install instructions unless a later complete release supplies and proves a specific upgrade path.

Envato license and activation boundary

The applicable Envato license selected at purchase governs use of Codable. Version 1.0.0 does not collect or transmit a purchase code, does not call an author licensing service, and does not expose in-app activation, refresh, deactivation, or installation-transfer controls.

• Keep your Envato account, invoice, and purchase record private; the application installer does not need them.
• Follow the license terms attached to the transaction and preserve all third-party notices in licenses/.
• Contact Envato or the item author through the legitimate item channel for purchase or license questions; do not send credentials or private hosting data.
• Do not use third-party “nulled”, activation-bypass, or replacement-license services.

Security hardening

• Serve only public/; enforce HTTPS; keep APP_ENV=production and APP_DEBUG=false.
• Back up the original APP_KEY; never rotate it casually because it protects encrypted state.
• Use unique database, SMTP, AI, runner, and administrator credentials; rotate them through their supported workflows.
• Keep the runner private, rootless, authenticated, resource-limited, and patched. Never execute generated code in the control plane.
• Run queue and cron as restricted users; deny public access to logs, storage, source archives, and backups.
• Use explicit trusted proxies, least-privilege firewall rules, secure cookies, account security, and tested backups.
• Apply only complete authentic future releases using their version-specific instructions; monitor System Health and audit records, and investigate repeated build or authentication failures.
• Review generated code and third-party content before publishing or distributing it.

If you suspect compromise, isolate the affected host, preserve logs, revoke exposed credentials, rotate runner signing/HMAC material using the documented trust procedure, restore from a known-good point, and contact the appropriate provider and author support channels.

Privacy and retention

The installation owner is responsible for a lawful privacy notice, processing basis, provider agreements, data location, retention, user requests, and incident handling. Codable's page templates are starting material and are not legal advice.

• Users can request a queued encrypted personal-data export. Defaults limit requests to three per day, expire exports after 24 hours, and cap encrypted output at 100 MiB.
• Account deletion is scheduled and can be cancelled while the UI permits; scheduled jobs process due deletion and retained cleanup. Review the configured policy rather than promising an undocumented grace period.
• Pending prompt attachments and temporary source/build artifacts have scheduled cleanup. Defaults are configurable and must match the published policy.
• Prompts and references may be sent to the selected external AI provider. Do not submit secrets, special-category data, or information you lack the right to process.
• Limit log access and avoid enabling debug output in production.

Troubleshooting method

1. Record the time, user, project, action, visible message, and correlation/reference identifier without copying secrets.
2. Open Admin → System Health and identify the first unhealthy dependency.
3. Inspect application and process-manager logs around that time. Keep debug mode off.
4. Confirm the queue process is alive with the documented queues and that the one-minute scheduler heartbeat is fresh.
5. For build errors, inspect both the AI run timeline and private runner logs; verify time synchronization, TLS, HMAC key identifier, public verification keys, Podman, resources, and locked toolchain.
6. Reproduce once with a minimal non-sensitive test project. Do not repeatedly spend credits before fixing the dependency.
7. If escalation is needed, share versions, sanitized logs, steps, expected/actual behavior, and the System Health result—not credentials, purchase records, prompts containing private data, or database dumps.

Common errors

Support boundaries

Use the support channel and support status shown on the Codable CodeCanyon item page. When the item is marked supported, support covers questions about the built-in documented features and assistance with reproducible product defects, subject to Envato's current Item Support Policy.

Support does not include installation or server administration performed for you, custom features or generated-site customization, unrelated third-party software, provider account approval or billing, content creation, legal/compliance advice, data recovery without a valid backup, or problems caused by modified/nulled code or an unsupported environment. Hosting, SMTP, AI, DNS, CDN, and VPS vendors retain responsibility for their services.

Never send passwords, private keys, API keys, purchase records, or unsanitized production data in a ticket. Envato's current guidance is linked in Topic 40.

Changelog

This package is version 1.0.0, the initial buyer release. The authoritative release history is CHANGELOG.md at the package root. Read it before installation or update; later versions may change requirements or add version-specific migration steps.

Credits, third-party licenses, and official references

Codable is proprietary product code distributed under the Envato license selected at purchase. It includes redistributable open-source dependencies under their own licenses. Review licenses/credits.html, licenses/third-party-licenses.txt, the hash-level asset inventory, the dependency compatibility review, and supplied SBOMs before redistribution or modification. Third-party package presence does not mean a dormant integration is release-enabled.

No stock photography, third-party font, music, video, or benchmark asset is represented as included by this documentation. Any separate item-preview media must be credited and licensed in the marketplace listing by the author.

The author submission must be one organized ZIP rather than a root-level file dump, remain below Envato's recommended 2 GB maximum, pass malware and rights review, and link to public online documentation. Marketplace metadata must match the shipped requirements and limitations, and the Code tag list must contain no more than 15 accurate tags. Before submission, review the final PHP for unique commercial utility, security, clean abstraction, maintainability, and complete documentation.

Envato references reviewed for this documentation

Rechecked on 9 August 2026. The reported source-page update dates remained unchanged. Envato may revise its rules; the author must recheck them immediately before submission.

• Code Item Preparation & Technical Requirements
• What Assets Can I Use In My Items?
• Item Information and Metadata Requirements
• Common Rejection Factors for Code Items
• Quality and Technical Requirements
• Item Support — Best Practices
• Item Support Settings for Authors
• Guidelines for Listings, Profiles, Item Comments and Ratings

These links are references, not a claim or guarantee that Envato will accept the item.