feat/bug: Laravel deployment issues – Service stuck in Stopped state, orphan container, missing database linking, web terminal/CLI & volume persistence

Problem Description

While deploying a standard Laravel application (cafe-payment) on Openship v0.4.8, several PaaS features and UI bugs were encountered that prevent proper deployment, management, and database configuration.

When accessing the deployed application, a QueryException is thrown:

Illuminate\Database\QueryException
Database file at path [/var/www/html/database/database.sqlite] does not exist. Ensure this is an absolute path to the database.

Additionally, attempting to fix or manage the service state results in dashboard errors and orphan containers.

Key Issues & Feature Requests

1. Service Stuck in Stopped State & Uneditable Settings (Bug)

When triggering Start or Redeploy on cafe-payment, the UI fails with:

cafe-payment
Service has no image or build configured.

• Uneditable UI: Settings (environment variables, build commands, framework settings) cannot be saved or modified once in this state.
• Orphan Container: Despite the UI showing Stopped, the web application remains reachable on its custom domain (cafe.minicenter.my.id). The underlying Docker container is still running, but Openship loses track of its state.

2. Database Provisioning & Service Linking (Feature Request / Bug)

• Although database services (e.g., MySQL) can be created under Apps & Services, there is no UI option or automatic mechanism to link/attach the database service directly to the application container.
• Connecting the app relies solely on manual environment variable injection with no native service discovery or linking.

3. Terminal / Web CLI Access (Feature Request)

• There is no built-in web terminal or CLI console in the Openship UI to execute commands inside running containers.
• This blocks common workflows such as:
  • php artisan migrate
  • php artisan db:seed
  • Creating missing files like database.sqlite

4. Persistent Volume Mounting & Storage (Feature Request)

• There is currently no UI setting to define or mount persistent Docker volumes to project directories (e.g., /var/www/html/storage or /var/www/html/database).
• Without explicit volume mounting, local databases (like SQLite) or uploaded files will be lost upon container update/redeploy.

Steps to Reproduce (UI / Container Bug)

1. Deploy a project (cafe-payment) on Openship v0.4.8.
2. Attempt to trigger a Redeploy or modify environment variables in Settings.
3. Observe the error toast:
   复制

   Service has no image or build configured.
   

4. Observe that the UI reports Stopped and settings cannot be saved, yet the website remains accessible via the configured domain.

Expected Behavior

• Service settings (environment variables, build configs) should remain editable at all times, regardless of service state.
• Redeploying should rebuild the image without losing container state tracking.
• The UI status should accurately reflect actual running Docker containers on the host.
• Database services should be attachable/linkable to application containers directly from the UI.

Questions for Maintainers

• Is volume persistence automatically configured for specific directories during build/deploy, or is custom volume management planned for future releases?
• Is there a recommended way to run build/migration hooks (like php artisan migrate --force) post-deployment?
• Is there a workaround for the orphan container / Stopped state bug while awaiting a fix?