Feature request: cross-project networking, host port exposure, and post-deployment hooks

[Vadime]

Is your feature request related to a problem? Please describe.
I am using QuickStack in production and overall it works really well. However, I ran into a few limitations that make some real-world deployment scenarios difficult.

The main issue is networking between apps that are deployed in different projects. If two apps are in two separate projects, I cannot reach them internally. Exposing them externally does not solve the problem either, because I run into a NAT issue: both apps end up using the same IP address, which causes conflicts and makes communication unreliable or impossible.

Another limitation is that apps can currently only be exposed through Traefik-oriented workflows. In some cases, I would like to expose an app directly on a node/host port instead. For example, I may want to run an SFTP pod and bind it directly to a host port on a specific node. At the moment, there does not seem to be support for this.

Finally, I understand that not exposing databases is a deliberate security decision. That makes sense for production. However, for development workflows, it would be very helpful to have some secure built-in access mechanism, for example WireGuard support or something similar, so databases and internal services can be reached safely during development.

Additionally, there is currently no way to run post-deployment or post-build logic. In many cases, it is necessary to run tasks such as database migrations or seeding after deployment. There is no built-in mechanism for this.

This also creates practical issues: for example, I am running Gitea inside QuickStack, but it cannot connect to its database because it is deployed in a different project. This ties back to the lack of cross-project networking, but also highlights the need for better orchestration or pipeline-like features.

Describe the solution you’d like
I would like QuickStack to support the following:
1. Cross-project internal connectivity
Apps deployed in different projects should be able to communicate internally in a reliable way, without IP/NAT conflicts.
2. Alternative exposure methods beyond Traefik
It should be possible to expose certain workloads directly via host/node ports, for example for services like SFTP, game servers, or other TCP-based applications that are not a great fit for Traefik.
3. Secure development access to internal services/databases
Even if public database exposure remains intentionally unsupported, it would be great to have built-in support for a secure developer access path, such as WireGuard or a similar VPN/tunneling solution.
4. Post-deployment hooks / pipelines
A way to run logic after build/deployment (e.g. migrations, seeding, setup scripts). This could be implemented as:
• simple post-deploy commands
• or more advanced pipeline/job support
5. Improved service orchestration across projects
Either through proper cross-project networking or another mechanism, so services like Gitea can reliably connect to their databases even when deployed in different projects.

Describe alternatives you’ve considered
For cross-project communication, I considered restructuring apps so they live inside the same project, but that is not always practical from an organizational or architectural perspective.

For non-HTTP services such as SFTP, I considered handling exposure outside of QuickStack, but that reduces the value of having a unified deployment platform.

For database access during development, external VPN or tunneling setups are possible, but built-in support would make the developer experience much smoother and easier to manage.

For post-deployment tasks, I considered handling migrations and seeding manually or via external CI/CD pipelines, but this breaks the deployment flow and adds operational overhead.

Additional context
This feedback comes from using QuickStack in production. In general, the experience has been very positive, and these points are the main gaps I have noticed so far.

[Vadime]

I’d be very interested in contributing to this as well.

If you think any of these features make sense, feel free to point me in the right direction (e.g. which parts of the codebase to look at or preferred implementation approach), and I can work on a PR.

Happy to align with your vision and priorities.

[DenisNovikau]

I have the same issue. External urls from the same server, cannot talk to eachother.

[biersoeckli]

Hi @Vadime

First of all, thank you for the detailed write-up and for using QuickStack.
I’ll try to address the individual points and give some context on the current behavior and possible directions.

1. Cross-project connectivity

The current networking behavior is largely by design. QuickStack currently isolates projects at the networking level using Kubernetes Network Policies under the hood. Each project gets its own "internal network" so that services inside a project can communicate via service name, but cross-project communication is intentionally not enabled by default. This is also the reason why communicating between different apps over an external domain is not possible (this is actually not intended and a bug)

The main reason for this is isolation and simplicity. Projects are currently treated more like isolated environments rather than just organizational folders. In the background each project has a separate namespace in the Kubernetes cluster. -> projectId = Kubernetes namespace name

However, there is a way to disable the network policies for an app so that communication between apps in different projects is possible. Just head to the app settings and go to „Advanced“ -> „Network Policies“ and disable them for the source app in project A and target app in project B. Make sure to redeploy both apps after changing settings.

Because the two apps are in different projects, they are in the context of Kubernetes also in different namespaces. So the hostname to reach App B in Project B from app A in Project A is different than the one for communication in the same project.

Currently the hostnames for communication are structured like this:

• Communication within the same project: svc-<app-id>:PORT
• Communication between apps in different projects: svc-<app-id>.proj-<project-id>.svc.cluster.local:PORT

The suffix .svc.cluster.local is always the same static suffix, and the service name always requires the svc- prefix before the app ID. The project id needs a proj- prefix and is visible in the url when selecting a project on the main page (project detail page with all apps running in the project).

Possible improvement -> In Networking “Expert View”
To solves your networking-problem in a more secure way, the Network Policies card could be extended with an “Expert View”.
The idea would be:

• The current UI becomes the “Simple View”
• An additional “Expert View” allows users to configure networking rules more explicitly, similar to a firewall

For example in the Expert view the configuration is possible in a „Firewall style way“:

• App A is allowed to send outbound traffic to App B in Project B
• App B allows inbound traffic on port 3000 from App A

This would make cross-project communication easier to configure and more transparent, while still keeping the simple networking model for most users.

2. Alternative exposure methods beyond Traefik

This is a valid point. In the domains tab a new card could be nice where users can define NodePorts. In the background the deployment would create a service with the nodePort property set.

const body: V1Service = {
    apiVersion: 'v1',
    kind: 'Service',
    metadata: {
        name: '...',
        namespace: '...',
    },
    spec: {
        selector: {
            app: '...'
        },
        ports: [
            {
                protocol: 'TCP',
                port: 1000,
                targetPort: 1000,
                nodePort: 1000, // this must be set to serve on NodePort of every node in the cluster
            }
        ],
        type: 'NodePort' // this also must be set to serve on NodePort 
    }
};

3. Accessing Databases and other services from remote in a secure way

@P4PER created a PR on this. He created a new template for chisel. #78 The PR contains a description with more details on how it works.
If this is not suitable for your use case, there may be other services that could be added as an app template to QuickStack to achieve the same goal. If you have a suitable option for an easy-to-maintain built-in solution, I would be open to it.

The chisel app template is in the next production release of QuickStack available.

4. Running Post-Deployment or Post-Build logic

This could be solved using init containers or sidecar containers.
Since Kubernetes is already running in the background to orchestrate the workloads, this should be relatively easy to implement.

Example:
I have a Node.js backend with a Postgres database. Before the main container starts, I want to run migration scripts (e.g. Prisma or Drizzle) so that the database schema is up to date before the application starts.

This could be solved with an init container that either:

• runs the same Node.js image with different startup arguments (e.g. npm run migrate), or
• runs a custom script (e.g. a bash script) provided through the QuickStack UI.

The main container would only start after the migration/init container has finished successfully.

---

I hope I didn’t forget something :)

If you're interested in contributing on these points, that would be very appreciated.
If you plan to implement all of the above, it would be best to split this into multiple PRs.

In order to test QuickStack locally during development, a VM (or another environment) with k3s running is required. To setup this env, idealy just install QuickStack on the VM using the install command curl -sfL https://get.quickstack.dev/setup.sh | sh -. This installs all the required components.

When cloning the repo: A kube-config.config file must be created in the root of the project containing the kubectl access credentials. The credentials are usually located on the VMwhere k3s is running on here: /etc/rancher/k3s/k3s.yaml

Example configuration (maybe insecure-skip-tls-verify: true needs to be added for dev env):

apiVersion: v1
clusters:
- cluster:
    insecure-skip-tls-verify: true
    server: https://SOME-IP-ADDRESS-OR-HOSTNAME:6443
  name: default
contexts:
- context:
    cluster: default
    namespace: registry-and-build
    user: default
  name: default
current-context: default
kind: Config
users:
- name: default
  user:
    client-certificate-data: .....
    client-key-data: .....

If you run into any issues, feel free to reach out.