Support source-less service projects for shared infrastructure such as Redis and PostgreSQL

[Frtrillo]

Problem

I would like to use Openship for production, but the current project creation and first-deployment workflow prevents me from creating a project that contains only infrastructure services.

Examples include:

• Redis
• PostgreSQL
• MySQL
• MongoDB
• Queues and other stateful services

Openship already supports these services as Docker images and allows them to be added to a project. However, the project must first be connected to an application template, Git repository, or local folder and deployed.

This forces users to create a placeholder application or attach infrastructure to an unrelated application deployment. That is confusing and unsuitable for production infrastructure.

Use case

I want to create a project such as Shared Services containing:

• One Redis instance
• One PostgreSQL instance
• Persistent volumes
• Backups
• Private networking
• Environment variables and credentials

These services may be consumed by multiple applications. The infrastructure project itself does not have application source code and should not require a repository, template, build command, or folder.

Current behavior

The CLI appears to support creating a services project:

openship project create \
  --name "Shared Services" \
  --slug shared-services \
  --type services

Services can then be added:

openship service create \
  --project shared-services \
  redis \
  --image redis:7-alpine \
  --port 6379 \
  --restart unless-stopped

However, the dashboard still requires connecting a source before the first deployment. It does not allow the image-only services to become the initial deployment.

Therefore, --type services does not currently provide a complete source-less deployment workflow.

Expected behavior

Openship should provide an Empty services project or Infrastructure project option.

Creating this project should:

1. Not require a Git repository, template, or local folder.
2. Open the project's Services screen immediately.
3. Allow adding services from the catalog or from any custom Docker image.
4. Allow configuring ports, commands, environment variables, secrets, health checks, persistent volumes, and backups.
5. Allow the first deployment to be created entirely from the configured service images.
6. Keep databases and caches internal by default.
7. Support a documented way for authorized applications or projects to connect to shared infrastructure services privately.
8. Permit subsequent service updates and redeployments without attaching application source code.

Suggested dashboard flow

New project
  └── Empty services project
        ├── Add Redis
        ├── Add PostgreSQL
        ├── Configure volumes and backups
        └── Deploy services

This would be similar to the service/application workflows available in platforms such as Coolify and Dokploy.

Why this matters

Shared databases, caches, and queues are normal production infrastructure. Requiring them to be attached to an unrelated application repository creates unnecessary coupling and makes ownership, deployments, backups, and lifecycle management less clear.

This limitation currently prevents me from using Openship as my primary production deployment platform. The underlying service functionality already appears to exist; what seems to be missing is a complete source-less project and first-deployment workflow.
That said, thank you for all the great work on Openship so far! I really like the platform’s direction and would love to use it for my full production stack. Adding this workflow would remove a major adoption blocker and make Openship even more useful in production environments.