Deploying
Deploy a web app or API
Create an app from a Git repository and deploy it as a Cloud Run service in your own Google Cloud project.
A service is an app that answers HTTP requests: a website, an API, a dashboard. Elula builds it from your Git repository with Cloud Build, stores the image in Artifact Registry, and runs it on Cloud Run, all inside your own Google Cloud project. Every service gets a URL.
If your code runs and exits instead of serving requests, deploy it as a job. See Jobs and schedules.
Before you start
- Your workspace has Google Cloud connected. Apps can't be created or deployed without it.
- Your workspace has an active subscription. See Billing.
- Your code is in a Git repository with a remote called
origin. For private GitHub repositories, connect the Elula GitHub App so Cloud Build can clone the code. - You have the CLI installed and are logged in. See Install and log in.
Deploy with the CLI
From the root of your repository:
elula init elula deploy
elula init reads the repository URL and current branch from Git, creates the app, and saves a .elula.json file that links this folder to it. elula deploy starts a build, says how long this app's deploys usually take, shows each step (queued, building the image, updating Cloud Run, live) with the time so far, and prints the URL when the app is live. In a terminal the build log streams between the steps; elula deploy --no-wait starts it and returns, and elula status --wait 60 follows it.
Useful elula init options:
elula init --name my-api # app name (default: the repo name) elula init --branch main # branch to build (default: current branch) elula init --database # add a managed Postgres database elula init --access private # private or public elula init --region us-central1 # asia-southeast1 (default) or us-central1 elula init --framework static # framework preset (default: auto) elula init --root-dir apps/web # build from a subdirectory
Then check on it:
elula status # app details and the latest deployment elula open # open the live URL in your browser
If an app already exists for this repository and directory, elula init links the folder to it instead of creating a second app. To link a folder to an app someone else created, use its ID (or an ID prefix):
elula link 3f2a9c1e
Deploy from the dashboard
- Go to Apps and choose New app.
- Pick Import a repo, choose the GitHub account and repository, or paste a repository URL.
- Elula scans the repository and shows what it detected: framework, build command, start command and port.
- Check the branch, framework, root directory, port, environment variables and access. Region and database are under Advanced / optional.
- Create the app, then click Deploy on the app page.
If the repository has a .env.example file, the dashboard pre-fills its keys as environment variables.
What happens during a deploy
- If the app has a database and none exists yet, Elula creates it.
- Cloud Build clones the latest commit of the app's branch from the remote repository.
- If an image for that exact commit was already built, Elula reuses it and skips the build.
- Otherwise the image is built. See Frameworks and Dockerfiles.
- The image is deployed to Cloud Run with your environment variables, scaling settings and access rules.
You can follow progress with elula status, elula logs (build logs) or the Deployments and Logs tabs.
elula deploy warns you about uncommitted changes and unpushed commits. Push first.Your app must listen on PORT
Cloud Run sends traffic to one port inside your container and sets the PORT environment variable to it. The default is 8080.
- Best: read
PORTfrom the environment and listen on0.0.0.0. - If your app uses a fixed port, tell Elula:
elula scale --port 3000, or set Port when creating the app in the dashboard.
const port = process.env.PORT || 8080; app.listen(port, "0.0.0.0");
import os
port = int(os.environ.get("PORT", 8080))The dashboard's repository scan looks for hard-coded ports in common entry files (such as server.js, index.ts, main.py, main.go) and pre-fills the port field when it finds one.
elula runtime-logs.Auto-deploy on push
When the app is connected through the GitHub App, every push to the app's branch starts a new deployment. The dashboard shows this on the app's Overview as "Every push to <branch> deploys this app."
- A push is skipped if a deployment for that app is already in progress. Run
elula deployafterwards if you need that commit live. - A push is skipped when the workspace can't deploy (for example, no active subscription).
- For apps in a subdirectory, a push only deploys when it changes files inside that directory. See Monorepos.
Access
New apps use the workspace default. Private apps can only be opened by people signed in with your verified team domain, so private apps need that domain verified first. Until then, new apps are public. See Private and public apps.
elula access # show the current setting elula access private # make the app private
After the first deploy of a private app, access can take 1-2 minutes to start working. If you see a permissions screen, wait and refresh.
Regions
Apps run in asia-southeast1 (default) or us-central1. To move an existing app:
elula project set-region us-central1
This redeploys the last successful image in the new region, then deletes the old one. The old service keeps serving until the new one is up. The app's URL changes. A database stays where it is.
Notifications
Elula emails the person who started a deployment when an app goes from failing to working, and when it goes from working to failing. Deploys started by a push are attributed to the app's owner.
Delete an app
elula project delete
This deletes the Cloud Run service or job, its database and its secrets, after you type the app name to confirm. Only the app's owner or a workspace owner or admin can delete it. In the dashboard, use Settings → Danger → Delete app.