Feature Guide

A quick orientation block that answers the essential questions: what this feature does, how it works, why it matters, and the key concepts behind it.

What this does

Create the project, review the baseline env contract, and bring up the Semitexa runtime the supported way.

Canonical Install

Create the project and get to a trustworthy first boot

Use the installer, review the shared env baseline, boot the runtime with the Semitexa CLI, and verify the project shape before you start authoring modules.

Step 1

Run the installer

The supported install path is the one-line installer. Use the named-directory form only when you want a specific folder immediately.

curl -fsSL https://semitexa.com/install.sh | bash

curl -fsSL https://semitexa.com/install.sh | bash

curl -fsSL https://semitexa.com/install.sh | bash -s my-project

curl -fsSL https://semitexa.com/install.sh | bash -s my-project

Step 2

Review the env boundary

Semitexa now writes `.env.default` as the committed baseline. Edit `.env` only when this machine needs overrides such as a different port.

cd my-project

cd my-project

$EDITOR .env

$EDITOR .env

Step 3

Boot and verify

Use the operator shell to start, check, and inspect the runtime instead of guessing from container state alone. After boot, open the local app in the browser and confirm you have a real page, not just a running container.

bin/semitexa server:start

bin/semitexa server:start

bin/semitexa self-test

bin/semitexa self-test

bin/semitexa routes:list --json

bin/semitexa routes:list --json

Default Runtime

Semitexa uses Docker as the supported local runtime boundary.
The default app URL is http://localhost:9502 unless `SWOOLE_PORT` is overridden in `.env`.
If you installed Semitexa Demo during setup, open http://localhost:9502/demo after boot to inspect working feature pages immediately.
You do not need host PHP or Composer for the normal local flow.

install.sh bin/semitexa .env.default .env self-test routes:list

Verified against Semitexa Ultimate 2026.09.19.1020

Installation

Installation in Semitexa should end with a running runtime and a trustworthy operator shell, not with half-finished setup notes.

Canonical flow

Create the project with the supported installer.
Move into the project directory.
Review .env.default as the shared baseline.
Create .env only when this machine needs local overrides.
Start the runtime with bin/semitexa server:start.
Verify the runtime with self-test, route inspection, and a real browser page load.

Commands

curl -fsSLo install.sh https://semitexa.com/install.sh
# verify checksum/signature from release notes before execution
bash install.sh
bash install.sh my-project
cd my-project
bin/semitexa server:start
bin/semitexa self-test
bin/semitexa routes:list --json

What to verify after boot

the application responds in the browser
bin/semitexa self-test reports a healthy runtime
route discovery is visible through routes:list
the project shape is inspectable before you start authoring modules

Why this matters

If the first boot path is ambiguous, every later problem becomes harder to diagnose. Semitexa should feel operationally legible from the first hour.

Right After Install

Do these checks before you touch business code

A clean first boot should be operationally legible. Use the CLI to confirm health, discovery, and current bindings before you start extending the project.

Run `bin/semitexa self-test` when startup feels suspicious instead of debugging blind.

Use `bin/semitexa logs:errors` as the first log command when the runtime did not boot cleanly.

Inspect `bin/semitexa ai:ask project --json` and `bin/semitexa contracts:list --json` early so you know what the project discovered.

If ORM-backed modules are active, treat `bin/semitexa orm:sync --dry-run` as part of the normal first setup path.

Boot Verification

What a clean first boot should prove

After `bin/semitexa server:start`, you should be able to verify the runtime from both the browser and the operator shell without guessing what happened.

Open `http://localhost:9502` and confirm the app responds with the starter page instead of a Docker, proxy, or browser error.

If Semitexa Demo was installed, open `http://localhost:9502/demo` and confirm the demo home renders before you explore deeper pages.

Run `bin/semitexa self-test` and expect a clean health check before you start debugging application code.

Run `bin/semitexa routes:list --json` so route discovery is visible instead of assumed.

Use `bin/semitexa ai:ask project --json` when you need to inspect what the scaffold and installed modules actually registered.