Skip to main content
Springwinter gives you six distinct resource types to build a complete application stack. Each type maps directly to a managed AWS service running inside your own account, so you retain full ownership of the underlying infrastructure. You can mix and match resource types freely within a project to compose the exact architecture your application needs.

​
Available Resource Types

Web Server

A containerized HTTP service with a public URL. Springwinter builds your Dockerfile from GitHub and runs the resulting image on Amazon ECS. Ideal for APIs, full-stack apps, and any service that needs to handle inbound HTTP traffic.

Worker

A background ECS process with no public URL. Workers share the same build pipeline as web servers but are not exposed to the internet — perfect for queue consumers, scheduled jobs, and data pipelines.

Static Website

A build-from-GitHub static site published to Amazon S3 and served globally through Amazon CloudFront. Ideal for single-page apps, marketing sites, and documentation.

Cache

A Valkey (Redis-compatible) instance running in your AWS account with TLS enabled and no password required inside your private network. Use it for session storage, rate limiting, pub/sub, and general caching.

Database

A fully managed PostgreSQL or MySQL instance provisioned by AWS RDS inside your account. Springwinter handles the instance configuration; you own the data and can connect directly at any time.

Storage

A private Amazon S3 bucket with built-in metrics and cost tracking. Use it to store user uploads, build artifacts, backups, or any binary data your application produces.

​
Resource Lifecycle

Every Springwinter resource follows the same general lifecycle, regardless of type:
1

Create

You define the resource through the dashboard or API — providing a name, configuration, and (for compute resources) the GitHub repository and branch to deploy from.
2

Build

For web servers, workers, and static websites, Springwinter triggers a build from your connected GitHub repository. Springwinter clones the branch, runs your Dockerfile or build command, and pushes the resulting artifact to your account.
3

Running / Available

Once the build succeeds, Springwinter provisions the underlying AWS resource (ECS task, RDS instance, CloudFront distribution, etc.) and marks the resource as running or available. Compute resources receive a URL at this point.
4

Redeploy

When you push new code to the connected branch or trigger a manual redeploy, Springwinter runs a fresh build and performs a zero-downtime swap. Configuration changes (environment variables, instance size) also trigger a redeploy for compute resources.
5

Teardown

Deleting a resource through the dashboard or API instructs Springwinter to deprovision the underlying AWS resource and stop incurring charges. The teardown is permanent — deleting a database removes both the RDS instance and its data.

​
Your Data Stays in Your Account

All resources run directly inside the AWS account you connected to Springwinter. Springwinter assumes an IAM role to manage resources on your behalf but never stores permanent credentials. If you disconnect from Springwinter or stop using the platform, every resource — your ECS tasks, RDS instances, S3 buckets, and CloudFront distributions — remains in your AWS account exactly as provisioned. You are never locked out of your own infrastructure.
You can monitor all resources from the Springwinter dashboard, which surfaces CloudWatch logs, CPU and memory metrics, request and error rates, and real-time cost estimates alongside a projected monthly run rate — all without leaving the Springwinter UI.