Menu
Platform
AI
App store purchases
Database
Flags
Jobs and cron
Localization
Monitoring
Notifications
Payments
Queues
Sandboxes
Webhooks
Getting Started
Authentication
KV Store
Deploy & Infrastructure
Reference
Hosting quickstart
A repository to a running app on a public URL, in five calls.
This takes a Git repository to an app answering over HTTPS. It uses the
management API at https://api.sylphx.com, which is how Hosting serves
customers today; the console does the same five things.
Today this runs on the management API
Hosting is served through the management API at api.sylphx.com, and every call on this page runs there. The services, source_links and service_rollouts collections of the API reference describe the one-API shape of the same product; the calls here are the ones to use.
sylphx api METHOD PATH sends one call with your key, and every call below is
also plain HTTP with Authorization: Bearer $SYLPHX_API_KEY.
#1. Create the project
A project holds the repository link and its environments. A new project comes
with production and preview.
sylphx api POST /v1/projects -d '{"name":"shop","gitRepository":"acme/shop","gitBranch":"main"}'The answer carries the project under app: its id (proj_…) and its
environments, each with its own id (env_…) and envType. Keep the project
id and the production environment id.
#2. Add the service
A service names the repository, the branch and the port the app listens on:
sylphx api POST /v1/projects/$PROJECT_ID/services -d '{
"name": "web",
"githubRepo": "acme/shop",
"githubBranch": "main",
"port": "3000",
"sourceKind": "git"
}'If the app lives in a sub-directory, and to open it to the internet, update the production environment:
sylphx api PATCH /v1/projects/$PROJECT_ID/environments/$ENV_ID -d '{"sourceRoot":"apps/web","publicNetworking":true}'GET /v1/projects/$PROJECT_ID/services lists the services, and
PATCH /v1/projects/$PROJECT_ID/services/web changes one, for example
{"instanceType":"nano"} for the smallest machine.
#3. Deploy
sylphx api POST /v1/projects/$PROJECT_ID/deploy -d '{"envType":"production","force":true}'This builds the commit at the tip of the branch and rolls it out. A push to the branch does the same, so after the first deploy you rarely call this yourself.
#4. Watch it go live
sylphx api GET /v1/deployments/projects/$ENV_ID/status
sylphx api GET /v1/deployments/projects/$ENV_ID/deployments
sylphx api GET /v1/projects/$PROJECT_ID/logsThe status moves to running when the app is live; unhealthy means the
deploy failed, and the logs say why. Each entry of the deployments list names a
build, and GET /v1/deployments/builds/{build_id} reads one in full.
#5. Open the app
Read the project back. The production environment's customDomains names the
host the app answers on:
sylphx api GET /v1/projects/$PROJECT_IDFor a host of your own, see Network.
#Clean up
sylphx api DELETE /v1/projects/$PROJECT_IDThis is the same sequence the Hosting journey runs against production, so it is checked against the live API.