Deployments & Build Logs¶
Every time your application is deployed -- whether triggered by a Git push, a webhook, or a manual action -- Appliku creates a deployment record that tracks the build and release process.
Deployment Statuses¶
Each deployment goes through a lifecycle and has one of the following statuses:
| Status | Description |
|---|---|
| New | Deployment has been created and is queued |
| Deploying | Build or release is actively running |
| Deployed | Deployment completed successfully and the application is running |
| Failed | Build or release encountered an error |
| Timeout | Deployment exceeded the maximum allowed build time |
| Aborted | Deployment was manually cancelled |
Waiting During an Appliku Update¶
When Appliku itself is being updated, new deployments do not start. A deployment that you start then stays New and shows Platform update in progress, starts soon. It starts automatically when the update is finished, usually after a few minutes. You do not have to deploy again. Deployments that already run are not stopped.
Viewing Build Logs¶
To view the build output for a deployment:
- Go to your application in the dashboard
- Open the Deployments section
- Click on any deployment record to expand its build logs
Build logs show the full output of the Docker build process, including dependency installation, asset compilation, and any errors that occurred. This is the primary tool for debugging failed deployments.
Triggering a Manual Deploy¶
You can deploy at any time from the dashboard:
- Go to your application overview
- Click the Deploy button
This pulls the latest code from the configured branch and starts a new build. Manual deploys are useful when you need to redeploy without pushing new code -- for example, after changing build settings, or environment variables that are used during the build.
You can also save build settings and deploy in one step: click Save and Deploy on the Build Settings tab of Application Settings.
Restarting Without a Build¶
To apply changed environment variables or process settings quickly, use Restart instead of Deploy. Restart does not clone the repository and does not build a new image. It starts the image that is running now again, with the current settings.
- Go to your application overview
- Click Restart, next to Deploy Now
- Confirm in the dialog
A restart is a deployment of its own. It shows in the deployment history as Restart (image from #N), where N is the deployment whose image it started.
Restart applies the current:
- environment variables (runtime values, see Build-time and runtime variables)
- process commands, scale, ports, resource limits and volumes, and processes that were added or removed
- nginx configuration for the default subdomain and custom domains
Restart does not:
- pull new code: the same image runs, even if the branch has new commits
- change anything that was computed during the build. Variables that your build command,
collectstaticor a frontend bundler read (for exampleNEXT_PUBLIC_*in Next.js) keep the values they had when the image was built. To change those, use Deploy. - read
appliku.ymlagain. The settings stored in the dashboard are used. The next full deploy appliesappliku.ymlagain. - apply changed build settings (build image, Dockerfile, build command). To apply them, use Deploy, or Save and Deploy on the Build Settings tab
- run the release command (for example
python manage.py migrate). Commands in your image's entrypoint still run when the containers start.
Each process is stopped and started again, so expect a short interruption per process. Restarts do not count toward the free plan's monthly deployment limit.
When Restart is not available, the button is disabled and shows the reason:
- the application has no successful deployment yet, or its running version was deployed before Restart existed: deploy once to enable Restart
- static sites: use Deploy
- the application moved to another server or cluster since the last deployment
A restart can also fail when the image is no longer on the server, for example after the server's Docker prune schedule removed it. Run a full deployment in that case.
Restarts and deployments queue together. If you start a restart while a deployment is still waiting in the queue (status New), the waiting deployment is aborted, and the other way round. A deployment that is already running is not affected.
Over the API, POST /api/team/{team_path}/applications/{application_id}/restart starts a restart (token permission deployments:create), and GET on the same path tells whether a restart is possible and why not (deployments:read).
Aborting a Deployment¶
If a deployment is in the Deploying state, you can abort it:
- Go to the active deployment in the Deployments section
- Click Abort
The deployment will be marked as Aborted and the previous version of your application continues running.
Post-Deployment Health Checks¶
If your team is connected to UptimeFor.me, every successful deployment starts an immediate run of the application's active HTTP monitors, and the results appear in the Monitoring block on the application dashboard. See Uptime Monitoring.
Deployment History¶
Appliku keeps a history of all deployments for each application. You can review past deployments to:
- Compare build times
- Identify when a failure was introduced
- See which commit triggered each deployment
Each deployment record includes the timestamp, status, and the associated Git commit (when available).