Managing Your App

Monitor, restart, redeploy, and inspect your running container from the portal

Opening the Manage panel

Go to dash.clouderized.com and select your app from the Applications view. Click Manage on the app card to open the detail panel. The panel has five tabs: Overview, Env, Domains, Files, and Logs.

Overview

Status, metrics, and actions

Env

Environment variables

Domains

Custom domain setup

Files

Browse persistent storage

Logs

Live container output

Overview tab

The Overview tab shows the live state of your container — updated whenever you open the panel.

Status badge

Shows Running when your container is healthy, Stopped when it has exited. If the container keeps crashing and restarting you may briefly see Running followed by a failed build in Deployment History.

CPU · RAM · Disk

The three progress bars show real-time resource usage. These are percentages of the limits assigned to your app in the Subscription view, not the whole VPS.

RAM

Memory used by the container process. A consistent 90%+ means you should raise the memory limit or reduce usage in your code.

CPU

CPU throttle percentage. Spikes are normal during request handling; sustained 100% means a CPU-bound workload may need a higher limit.

Disk

Storage used by your container image, git history, and /app/data files combined. Your tier's storage limit is shown in the Subscription view.

Uptime and URL

Uptime resets every time the container restarts — a Restart action or a new deploy both reset it. The Open → link takes you to your app's live URL (your-name.clouderized.com or your custom domain if one is configured).

Restart vs Redeploy

Both buttons are on the Overview tab. They are different operations:

Restart

Stops and starts the current container image. No build, no code change — identical to running podman-compose restart on the VPS.

Use when:

  • App is stuck or unresponsive
  • You changed an env var and want a quick reload
  • Clearing an in-memory cache or open connection

Redeploy

Triggers a fresh build from your latest main branch in Gitea — equivalent to a git push clouderized main.

Use when:

  • You pushed new code and the deploy didn't trigger
  • You want to force a clean build (no layer cache)
  • Recovering from a failed deploy
Redeploy takes time. A first build can take 60–90 seconds; incremental builds are faster. The portal shows a live progress indicator while the build runs. If the build fails, check Deployment History for the error output.

Deployment History

The Deployment History ↗ link opens the Gitea Actions run list for your app. Each push (or manual Redeploy) creates one workflow run. Click any run to see the full build and deploy log.

Green check — build succeeded, container is live.

Red X — build or health check failed. Click the run, then the failing step to read the error. Common causes: missing dependency in Dockerfile, wrong EXPOSE port, startup crash (also check Logs tab).

Yellow spinner — build in progress. Navigating away won't cancel it.

Logs tab

The Logs tab shows the last ~200 lines of stdout and stderr from your container — the same output you would see with podman logs. Scroll to the bottom for the most recent lines; click Refresh to pull the latest.

What to look for

OOMKilled

Container hit its memory limit and was killed. Raise the RAM limit in the Subscription view, or reduce memory usage in your app.

Exited (1)

Process crashed on startup. The lines above this message usually contain the Python traceback, Node.js exception, or JVM stack trace.

Connection refused

App can't reach a dependency (database, cache). Check that DB_HOST and other env vars are set correctly in the Env tab.

Listening on :8080

Your server started successfully and is bound to the expected port. If your app isn't reachable, confirm the port matches what's in your Dockerfile's EXPOSE instruction.

Logs are not persistent across restarts — the Logs tab always shows the current container's output. For a deployment's build log (e.g. why the build failed) use Deployment History instead.

Files tab

The Files tab is a read-only browser for your app's /app/data directory — the persistent volume that survives container restarts and redeploys. You can inspect what files your app has written, navigate into subdirectories, and check that seeded files are in place.

Common uses:

  • Confirm a SQLite database file was created at startup
  • Check that uploaded files are landing where the app expects them
  • Verify that a log file or cache directory was seeded correctly from the Docker image

Only /app/data is mounted as persistent storage — any files written elsewhere in the container (e.g. /tmp) are lost on restart. See Persistent Storage for details on how this works.

Env and Domains tabs

Env tab

Add, edit, and reveal environment variables. Values are masked by default. Click Save Changes to write to app.env and sync the Gitea secret in one step, then redeploy.

Environment Variables guide →

Domains tab

Add a custom domain (api.yourdomain.com), copy the CNAME target, and verify DNS propagation — all from this tab.

Custom Domains guide →