Skip to main content

Projects and infrastructure

A Kumoto project is the home for one application or service and the infrastructure it relies on. It gives you a visual canvas for the components that make up that system, such as an application, a database, a cache, or a scheduled task.

Start with one project for each application you want to deploy independently. For example, you might create one project for a customer-facing web application and another for an internal worker. Keeping their infrastructure separate makes ownership, changes, and deployments easier to understand.

Build on the canvas​

Add components to the project canvas, then choose the server where each component should run. Components can include application runtimes, container-based services, databases, caches, and cron jobs.

A simple web application might contain:

  • A Node.js, Laravel, Rails, Docker, or static-site component for the application.
  • A PostgreSQL or MySQL database for persistent data.
  • Valkey or Memcached when the application needs caching or short-lived shared state.

Connect components that depend on one another. A connection makes the relationship clear in the canvas and can make compatible connection values available to the consuming application. This avoids copying configuration by hand and helps keep the application pointed at the right service as the project changes.

Work safely in drafts​

Kumoto separates your planned configuration from what is currently running. Adding, updating, linking, or removing a component changes the project's draft; it does not immediately change your deployed infrastructure.

This makes it safe to prepare related changes together. You can add a database, connect it to an application, configure the application, and then deploy the complete change as one revision.

When you are ready, select Review and deploy. Kumoto shows the pending changes so you can confirm what will be created, updated, or removed before starting the rollout.

Configure each component​

Select a component on the canvas to configure it. The available options depend on its type, but commonly include:

  • Settings for the runtime, source, resources, and deployment target.
  • Variables for application configuration. You can add your own values, use built-in values, or import compatible values from a connected component.
  • Domains for HTTP applications that need to receive public web traffic.

Treat secrets and production configuration with care. Review variable changes before each deployment and avoid placing sensitive values in source repositories or shared configuration files.

Before you deploy​

Use the review step as a short operational checklist:

  • Confirm that every component has the intended server.
  • Check that applications are connected to the services they need.
  • Review source, variables, and domain changes.
  • Make sure removals are intentional, especially for databases or other stateful services.

Deployments run asynchronously, so you can follow their progress from the project after you start one.

Discard a draft​

If you decide not to ship pending work, reset the draft to return it to the last deployed revision. Resetting discards all unpublished changes in that project, so use it only when you are sure those changes are no longer needed. This option becomes available after the project has a deployed revision.