Skip to content
Console
Menu

Queues

Workflows

Getting Started

Authentication

KV Store

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:

Shell
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:

Shell
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

Shell
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

Shell
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/logs

The 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:

Shell
sylphx api GET /v1/projects/$PROJECT_ID

For a host of your own, see Network.

#Clean up

Shell
sylphx api DELETE /v1/projects/$PROJECT_ID

This is the same sequence the Hosting journey runs against production, so it is checked against the live API.

#Next