Minimal Documentation Lynfera

Build and Deploys

Builds

Lynfera automatically performs a build every time you start a deployment in the UI

Build infrastructure

When you initiate a build, Lynfera creates a secure, isolated virtual environment for your project:

  • Your code is built in a consistent, clean environment
  • Build processes can't interfere with other users' applications
  • Security is maintained through complete isolation

How builds are triggered

Builds can be initiated in the following ways:

  • Dashboard deploy: Clicking Deploy in the dashboard or creating a new project triggers a build.
  • Git push: Builds can also be triggered via code push events from Git providers if the project is connected via any Git provider App. Learn more

Build customization

Commands like build command and the install command are initially set by Lynfera. You can override them depending on your framework in the project settings tab or while creating a new project.

  • Build Command: Default build command (npm run build).
  • Install Command: Default install command is npm install.
  • Output Directory: Specify the folder containing your final build output (e.g., dist or build).
  • Root Directory: Path Where your code is in your repo (e.g., / or /frontend) Default value: / . Your app will not be able to access files outside of that directory. You also cannot use .. to move up a level

Environment variables

Lynfera can automatically inject environment variables such as API keys, database connections, or feature flags during the build:

Lynfera injects your environment variables into the build process during install and build..

Build output and deployment

Once the build completes successfully:

  • Lynfera uploads your build artifacts (static files and other assets) to the public cloud (s3).
  • A unique deployment URL is generated (apart from the project link) (Both URLs can be used to access the deployment).
  • Logs and build details are available in each project section of the dashboard.

If the build fails or times out, Lynfera provides diagnostic logs in the dashboard to help you troubleshoot. For common solutions, see our build troubleshooting docs.

Build Status

Every deployment and project has a status that reflects its current state. Understanding these statuses helps you track your deployment progress.

NOT_STARTED

Initial status when a project is first created. No deployment has been attempted yet.

Applies to: Project only

QUEUED

Deployment has been requested but hasn't started yet. Waiting for available build resources (similar to AWS ECS or GitHub Actions runner queue).

Applies to: Project and Deployment

BUILDING

Build has started. The first task (git clone) is in progress. Goes through 6 steps: cloning files, verifying cloned files, installing, building, verifying output files, and uploading assets.

Applies to: Project (first deployment only) and Deployment

Note: For subsequent deployments, the project shows READY (from previous deployment) while the new deployment shows BUILDING.

READY

Build completed successfully. Project is live and accessible.

Applies to: Project and Deployment

CANCELLED

Build was cancelled by the system during verification steps due to limits (number of files, file size), invalid code, or dangerous code detected in source files.

Applies to: Project (first deployment only) and Deployment

Note: For subsequent deployments, the project remains READY (previous deployment is still active).

FAILED

Build failed during install or build steps due to errors in your source code, build configuration, or rarely due to runner errors.

Applies to: Project (first deployment only) and Deployment

Note: For subsequent deployments, the project remains READY (previous deployment is still active).

Build Flow

This diagram shows how a deployment moves through different states from creation to completion.

NOT_STARTED
Project created
Deployment requested
QUEUED
Waiting for build runner
Build runner available
BUILDING
1.Cloning files
2.Verifying cloned files
3.Installing dependencies
4.Building application
5.Verifying output files
6.Uploading assets to S3
Steps 3-4 can be skipped via env vars
Verification failed
(steps 2 or 5)
CANCELLED
Invalid/dangerous code
Build error
(steps 3 or 4)
FAILED
Source code errors
All steps
successful
READY
Deployment live

Project Status Behavior

  • First deployment: Project status mirrors deployment status
  • Subsequent deployments: Project stays READY (showing previous successful deployment) even if new deployment is BUILDING, FAILED, or CANCELLED
  • Project updates: Only when new deployment reaches READY does the project status update and switch to the new deployment

Build Duration

The total build duration is shown on the Lynfera deployment Dashboard and includes all six steps: cloning files, verifying cloned files, installing, building, verifying output files, and uploading assets.

A Build can last for a maximum of 30 minutes. If the build exceeds this time, the deployment will be cancelled and the error will be shown on the Deployment's page saying this message Failed to start build runner / Build timeout exceeded.

Lynfera enforces strict limits on build execution to ensure platform stability:

  • Install Command: Max 10 minutes.
  • Build Command: Max 15 minutes.
  • Total Session: Max 30 minutes.

💡 Tip: You can skip the install and/or build steps by setting LYNFERA_SETTING_SKIP_INSTALL or LYNFERA_SETTING_SKIP_BUILD environment variables. Learn more

Limits and resources

Lynfera enforces certain limits to ensure reliable builds for all users:

  • Build timeout: The maximum build time is 30 minutes. If your build exceeds this limit, it will be terminated, and the deployment fails.
  • Concurrency: Max concurrent builds for each user is decided by their plan (free - 1, pro - 3).
  • Container resources: We fairly give both sets of users (free, pro) container with a limit of 2 vCPUs and 4 GB RAM for now but these values may change in the future.
  • Build image: Builds in Lynfera get a base image of Node:22-bookworm. You can view the generated image here

Deployments

A deployment on Lynfera is the result of a successful build of your project. Each time you deploy, Lynfera generates a unique URL to the live environment. The current project is also updated based on the deployment status.

Using the Dashboard

Lynfera's dashboard provides a centralized way to view, manage, and gain insights into your deployments.

When you select a deployment from your Project → Deployments tab, you can view each of the project’s deployments. Each deployment gives you insight into run time, logs, output files.

Files → Static Assets: Files (HTML, CSS, JS) and their sizes.

Managing Deployments

From the Deployments tab, you can:

  • Inspect: View logs and build outputs.
  • Promote to Production: Convert a preview deployment to production (if needed).

Environments

By default, Lynfera provide only a Production Environment.

  • Inspect:View logs and build outputs.
  • Promote to Production:Convert a preview deployment to production (if needed).

Delete a deployment.

You can delete failed or cancelled deployments directly from the deployment page using the Delete button.

For successful deployments, deletion is available only via API:
https://lynfera-api.hf.space/api/projects/[id]/deployments/[deployment_id] via a DELETE method that accepts deployment deletion requests.

By default this changes project's current deployment to its previous one if current deployment is given to delete.

This action is strongly discouraged due to the risk of disrupting the active deployment. This can unintentionally change the active deployment or result in a failed deployment state.

Redeploy a project.

Redeployment can be done by the project dashboard via three dots → Create New Deployment.

Redeployment is required whenever environment variables are added, changed, or updated.

Promoting Deployments.

This is a method to manually chnage your project's current deployment to another old one without creating a new deployment

Promoting an older deployment may alter the currently active version of the project. Users may observe changes to the live site upon refresh.

To change a project deployment:

  • Go to your project's Deployments tab
  • Click the three dots.
  • Select the option of promote deployment

You can't change the project to a failed deployment.

More Actions

  • Subdomain: A new random Subdomain is given to project when it is created. You can change it before or after deployment to have your own custom subdomain.
  • Disable/Enabling Project: Disabling project makes it not accessible to anyone. Accessing the project will display a project disabled page.
  • Delete Project: Deleting project can be done via settings tab of project. This action permanently deletes the project.

Enjoying the docs? If our platform has been helpful, consider giving us a ⭐ on GitHub — it is really appreciated!

⭐ Star us on GitHub