Web services

A web service is an app that answers HTTP requests, such as a website, an API or a backend. Appentic builds it from a branch of a GitHub repository, runs it on one of your project's machines and serves it over HTTPS at its own appentic.app address. You need a machine in the project first.

Create the service

1. On the project's Services page, click Add next to Web Services.
2. Under Connect a repository, search for the repository and select it. If you haven't connected GitHub yet, click Connect GitHub first. See GitHub.
3. Under Configure your service, check the settings:
   • Branch: the branch to deploy. It defaults to the repository's default branch.
   • Runtime, Build command and Start command. Appentic fills these in from the repository. If the repository has a Dockerfile at its root, the form shows Dockerfile detected and builds with it. See Builds.
   • Machine: where it runs. The list shows how much memory each machine has free.
   • Guaranteed memory: the service's share of its machine. CPU and disk follow the same share. See Memory and sizing.
   • Connect database and Connect key value store: shown when the project already has one. Connecting one sets DATABASE_URL or REDIS_URL on the service.
   • Auto-deploy: on by default. Every push to the branch deploys it. See Deploys.
   • Feather app (Feather repositories only): can also create a database, a key value store and a worker for the app. See Feather.
   • Price: what the service costs a month.
4. Click Deploy service.

The service is named after the repository. You can rename it later.

Appentic opens the service's Events page, where the build and deploy appear as they happen. A first deploy usually takes 2 to 4 minutes.

The Release command and Health check path are on the create form only for Feather apps. For any other app, set them in the service's Settings after you create it. See Release commands and health checks.

Your appentic.app address

Each web service gets an address on appentic.app based on its name, for example my-app.appentic.app. If that name is taken, Appentic adds a short random suffix, like my-app-3f9a1c.appentic.app.

Renaming the service doesn't change its address. To choose another one:

1. Open the service's Settings.
2. Under Domains, type the new name in Appentic address.
3. Click Update.

A name is 3 to 40 lowercase letters, numbers and single hyphens, and starts and ends with a letter or number. The address you're changing from keeps working, so links you've already shared still open the app. Only the most recent old address is kept: change it again and the oldest one stops working. The service restarts, and the new address works within about a minute.

While the service has custom domains, its address is fixed, because their DNS records point at it. Remove them first to change it.

The URL section on the service's Overview shows the address once the service has deployed, together with any active custom domains. The globe beside each address opens it, and its colour follows the service's status.

Status

The service's status shows on its Overview and in the project's list. The list also shows when it last changed, for example ● Live · 37m ago.

When the app keeps stopping

If a live service's app keeps exiting or failing to start, its status changes to Crashing. The Overview shows a Why line with the reason, usually the last error from the app's logs, and an Open its logs link. The event also appears on the Events page, and under the bell if Resource failures is on in notifications.

When the app stays up again, the status goes back to Live by itself.

A new deploy whose app keeps stopping as it starts fails straight away with the same reason, and the version that was live keeps running.

The service pages

Settings

A load balancer member has no Domains or Who can reach it sections, because visitors reach it through the load balancer.

Environment variables

Set variables on the project's Environment page, for every service or only the ones you choose. See Environment variables.

Private services

Turn on Private under Who can reach it to take the service off the internet. Your other services, and your own devices over private access, still reach it at its private address. See Private services.

Code fixes

Code fixes, under Build & Deploy, lets Athena and your coding agents push fixes to the service's repository. It's off by default. See Code fixes.

One instance

A web service runs as one instance. To handle more load, give it more memory, change its machine to a larger one, or run the same app as more web services, on more machines, behind a load balancer.

Move it to another machine

When the project has more than one machine, the service's Settings have a Machine section.

1. Pick a machine under Move to.
2. Click Move and confirm.

The service redeploys there with its current code, which takes a minute or two, and its address follows it. A move to a machine in another zone builds the service again there.

A web service with workers or cron jobs can't move to another zone while they are attached. Move or delete them first. See Machines.

Delete a web service

1. Open the service's Settings.
2. In the Danger Zone, click Delete service and confirm.

This deletes the service with its deploys, environment variables and events, and removes it from any load balancer. It also deletes any workers and cron jobs attached to it, which the Danger Zone lists. It can't be undone.

If deleting fails, the Danger Zone shows why and a Retry delete button.