Download the PHP package stewart-php/skeleton without Composer
On this page you can find all versions of the php package stewart-php/skeleton. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.
Download stewart-php/skeleton
More information about stewart-php/skeleton
Files in stewart-php/skeleton
Package skeleton
Short Description A new Stewart project: Home Assistant automations in PHP
License proprietary
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 skeleton
My Stewart automations
Home Assistant automations in PHP, built on Stewart.
You need Docker with Compose and a long-lived access token from Home Assistant (Profile → Security). PHP and Composer
run in the container; nothing else is installed on your machine. vendor/ lives in this directory, so your IDE sees
the whole framework source.
Start
Fill in STEWART_HOME_ASSISTANT__URL and STEWART_HOME_ASSISTANT__TOKEN in .env, then:
make help lists every target.
Writing an app
An app is a class in apps/ that implements Stewart\Contracts\App and carries #[Automation(id: '…')];
apps/HelloApp.php is one. Constructor parameters are injected by type (HaContext, a PSR logger, Scheduler,
Store, Clock, your own services from services.php) or filled from the app's options in stewart.yaml.
Import generated classes with use App\Generated\…;. Inside namespace App, a qualified App\Generated\X would
resolve against the imported Stewart\Contracts\App interface instead.
Generated classes
generated/ is committed: builds and deployments never need Home Assistant to produce it. Run make generate after
adding devices and commit the result; the daemon logs a warning when it no longer matches Home Assistant. The classes
name your entities, so keep this repository private if that matters to you.
Entities are looked up by their ID, so a search for light.hall finds every use. An ID from options works the same:
An ID missing from the last make generate throws IdentifierError::EntityNotGenerated.
Developing next to a running production daemon
Both would run every automation against the same Home Assistant. While developing, run only the app you are working on, and keep service calls from reaching Home Assistant:
Configuration
stewart.yaml holds what differs from the defaults; make config-reference lists every setting and make config
shows what is in effect. Every setting can also come from the environment: STEWART_, then the keys uppercased and
joined by a double underscore (apps.hello.options.watch → STEWART_APPS__HELLO__OPTIONS__WATCH).
- Secrets belong in
.envor in files:STEWART_HOME_ASSISTANT__TOKEN_FILE=/run/secrets/hareads the token from a file, which fits Docker and Kubernetes secrets. STEWART_BOOT_*variables are read by the container entrypoint, not by Stewart; they are listed below.
Deploying
Pick one. Each runs ghcr.io/stewart-php/runtime, an image that holds PHP and an entrypoint but not your code; the
framework version always comes from your composer.lock.
A checkout on the server
An image built by CI
.github/workflows/image.yml builds this repository into ghcr.io/<owner>/<repository> for amd64 and arm64 on every
push to main and every v* tag. Copy deploy/compose.image.yaml and a filled-in .env to the server, set the
image, and docker compose -f compose.image.yaml up -d. Kubernetes runs the same image (below).
A clone on every start
Copy deploy/compose.git.yaml and a filled-in .env to the server, set the repository URL, and
docker compose -f compose.git.yaml up -d. Every start fetches the ref and installs what changed; restart the service
to deploy. A private repository needs a read-only token (see the comments in the file).
| Entrypoint variable | Meaning |
|---|---|
STEWART_BOOT_GIT_URL |
Clone or fetch this repository into /app before starting |
STEWART_BOOT_GIT_REF |
Branch, tag or commit; main by default |
STEWART_BOOT_GIT_TOKEN_FILE |
File holding an HTTPS token for a private repository |
STEWART_BOOT_GIT_SSH_KEY_FILE |
File holding an SSH deploy key, for git@… URLs |
STEWART_BOOT_COMPOSER |
auto installs when composer.lock changed, always, or never |
STEWART_BOOT_GENERATE |
1 regenerates the classes from Home Assistant before starting; a failure keeps the committed ones |
Kubernetes
The chart runs one replica (two would both run every automation), probes the daemon with stewart status, and can
run Valkey for you. Its README lists every value, including code.mode=git for a clone on every start.
Upgrading
Dependabot proposes Stewart releases and runtime image tags. A minor release on 0.x may break; read its "Upgrading"
notes in the changelog before upgrading. Keep the
image tag in Dockerfile and the compose files on the same minor as stewart-php/runtime in composer.lock;
make upgrade moves both together.
License
The skeleton this project started from is MIT-0, so none of it needs attribution. composer.json declares the project
proprietary; change it if you publish your automations under a license.
All versions of skeleton with dependencies
psr/log Version ^3.0
stewart-php/codegen Version ^0.6
stewart-php/contracts Version ^0.6
stewart-php/mqtt Version ^0.6
stewart-php/runtime Version ^0.6
stewart-php/store-redis Version ^0.6
symfony/dependency-injection Version ^7.4 || ^8.0