Download the PHP package pinoox/app without Composer
On this page you can find all versions of the php package pinoox/app. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.
FAQ
Example:
In general, it is recommended to use always a project to download your libraries. In an application normally there is more than one library needed.
- Some hosting areas are not accessible by a terminal or SSH. Then it is not possible to use Composer.
- To use Composer is sometimes complicated. Especially for beginners.
- Composer needs much resources. Sometimes they are not available on a simple webspace.
- If you are using private repositories you don't need to share your credentials. You can set up everything on our site and then you provide a simple download link to your team member.
- Simplify your Composer build process. Use our own command line tool to download the vendor folder as binary. This makes your build process faster and you don't need to expose your credentials for private repositories.
Informations about the package app
pinoox/app
Single-app Pinoox project for Pinoox. Your project root is the app — no apps/ folder, no manager.
Quick start
While pinx dev is running, open /~inspector on the same local server for Pinx Inspector. Inspector is installed from Packagist as pinoox/pinx-inspector in require-dev and is not needed in production.
New projects include a minimal .env:
Use .env.example as the full reference when you want to override defaults or connect MySQL/PostgreSQL/SQLite.
DevDB is installed from Packagist as pinoox/devdb in require-dev, so local projects can run migrations and models immediately without setting up a database server. For production, set a real database connection and install dependencies without dev packages.
The template ships with default identity com_pinoox_app / Pinoox App so it runs immediately after install. To use your own package name, run pinx init --package=com_vendor_app --force or edit app.php, platform/, namespaces under Controller/ / Router/, and routes/.
Or with global pinx CLI:
Commands
| Command | Description |
|---|---|
pinx setup |
Migrate platform + app, run seeders |
pinx sync |
Add missing single-app support files |
pinx repair |
Repair this folder so it runs as a Pinx single-app project |
pinx dev |
Local HTTP server (and Vite when configured) |
pinx inspector |
Standalone local browser dashboard for database tables, schema, routes, logs, and runtime health |
pinx migrate |
App migrations |
pinx build |
Build ~pinx/export/{package}/*.pinx for platform install |
pinx release |
Bump version + build signed-ready package |
pinx doctor |
Check PHP, paths, and layout |
Layout
Config layers (do not mix)
| Layer | Path | Examples |
|---|---|---|
| Pincore (framework) | vendor/pinoox/pincore/config/ |
database, paths — read-only |
| Project deploy + dev host | platform/ |
apps.config.php, app-router.config.php, domain.config.php, launcher/ |
| Your app | config/ |
app.config.php, query_route.config.php, custom *.config.php |
platform/ and storage/ are not included in pinx build output unless you add them to build.include. They are only for local development; production installs use the host Pinoox platform's own config and storage.
PINOOX_PROJECT_CONFIG_PATH=platform in .env points pincore at this folder (default when platform/ exists).
Deploy to production platform
pinx buildorpinx release --sign- Upload the
.pinxfile to a full Pinoox installation - Install via Manager → Applications
pinx build packages your app for installation on a full Pinoox platform. It applies system defaults automatically (excludes platform/, storage/, vendor/, bin/, .env, dev tooling, …) and bundles only Composer require packages when present — never require-dev or pinoox/pincore. Override in app.php only when needed:
Monorepo development
When working inside the pinoox/pinoox repository:
GitHub releases
This template includes .github/workflows/release.yml. When you publish a GitHub Release, CI builds a .pinx install package and attaches it to that release.
Release asset name: {repo-name} v{version}.pinx — for example app v1.0.0.pinx on pinoox/app. If version-name in app.php already starts with v, it is not duplicated.
Suggested flow:
Make sure version-name in app.php matches the release before you tag. CI does not bump versions — it builds from the tagged commit.
Package signing
Pinoox signs .pinx packages with Ed25519 (PHP sodium). A signed build adds signature.json inside the archive. On install, the platform can verify integrity and block updates from a different publisher.
Generate a signing key (once)
Default key path for this layout:
Add to .gitignore:
Publish the public key (from sign.key.json) in your README or docs. Keep the secret key local and in CI secrets only.
Enable signing in app.php
Then build locally:
Sign in GitHub Actions
Store the full contents of sign.key.json as repository secret PINX_SIGN_KEY, then extend the release workflow:
If pinx.sign.enabled is true in app.php, --sign is optional — the build signs automatically when the key file exists.
Trust on the install platform
| Level | Setting | Meaning |
|---|---|---|
| Default | PINX_VERIFY=true |
Verify signature when signature.json is present |
| Official market | trusted_keys in pinx.config.php |
Only allow known publisher public keys |
| Strict | PINX_REQUIRE_SIGNATURE=true |
Reject unsigned packages |
Example for a trusted publisher on a full Pinoox platform:
What signing guarantees
- Integrity — manifest and payload were not tampered with after signing.
- Publisher continuity — updates must come from the same key (stored in
.pinx/identity.jsonon the installed app).
Without trusted_keys, anyone can ship a signed package with their own key. For official releases, publish your public key and register it on target platforms.
Do not
- Commit
pinx/sign.key.jsonto a public repository. - Put
secret_keyinapp.php,.env, or workflow logs. - Rotate signing keys without documenting the new
key_idand fingerprint in release notes.
