# Runless - Stop Paying for Idle AWS Dev & Staging Environments Source: https://runless.cloud --- Runless SaaS for AWS Cost Optimization Link AWS accounts in minutes, automate ECS and EC2 schedules from one multitenant control plane, and stop paying for idle resources. --- Stop Wasting Money on Idle Development Environments Development and staging ECS services and EC2 instances running 24/7? You're paying full price for resources used only during business hours. **The Problem:** - Development and staging environments idle 60-70% of the time - Teams forget to shut down environments after work hours - Weekend and holiday costs add up quickly - Manual management is time-consuming and error-prone **The Impact:** Save **$500-5000+ monthly per environment** with automated resource management. Typical ROI in the first month. --- Pilot Program Prove it out before you commit, billed through a private offer Want to see Runless working on your own dev or staging environment before signing up on the public listing? We run a short, guided pilot: you connect one AWS account, we help you configure schedules for a real workload, and we issue an **AWS Marketplace private offer** for it - so billing and procurement stay inside your AWS account from day one. **What you get:** - A scoped pilot on a real dev or staging environment, priced as a private offer - 20-minute setup via the CloudFormation Quick Start - your credentials never leave your account - A direct line to the founder - your feedback shapes the roadmap - Terms that carry over into your ongoing subscription **What we ask:** - Connect at least one real dev or staging environment - Short feedback notes or a call about once a month - Optionally, permission to share your anonymized savings numbers Ask about a Pilot Tell us briefly what runs in your dev/staging accounts (ECS, EC2, roughly how many resources), and we'll scope the pilot and private offer with you. --- How Runless Works SaaS onboarding and account automation in four steps 1. Subscribe & Launch Quick Start Subscribe in [AWS Marketplace](https://aws.amazon.com/marketplace/pp/prodview-fyqtjjmncqlbi) and launch the Quick Start stack in your AWS account. The stack creates a scoped cross-account access role and outputs a secure portal link. 2. Sign In to Runless Open the portal link, create your Runless account (or sign in), and complete AWS account linking using stack outputs. 3. Verify & Activate Runless verifies role trust, external ID, and minimal read access, then reconciles commercial access before the account is marked active. 4. Automate Runtime Configure schedules per resource, cluster or region, queue manual actions, and monitor savings across all linked accounts from one dashboard. --- Features Everything you need to optimize AWS costs Smart Scheduling Define custom schedules per ECS cluster/service or EC2 instance/region Business hours automation Weekend handling Manual + Automated Control Instant ON/OFF toggle ECS service and EC2 instance dashboards Mobile-friendly interface Bulk start/stop operations Quick actions Cost Analytics Real-time savings tracking Detailed usage reports Cost forecasting Per-resource savings history Security & Compliance Cross-account role access with external ID Least-privilege AWS permissions CloudTrail-compatible audit visibility Complete audit logs Change history tracking SaaS Onboarding Marketplace Quick Start compatible Portal-based account linking Verification and commercial checks No customer-hosted control plane required Fast account offboarding Team & Tenant Management Shared tenant workspace per customer Owner/member roles Seat-aware invitations Connection health lifecycle Centralized governance --- Perfect For... Common use cases where Runless saves money Development Environments Turn off during nights and weekends. Save **60-70%** on dev costs with automatic morning startup. No developer overhead required. Staging & QA Environments Schedule around testing cycles. On-demand activation for deployments. Cost control for multiple stages with team coordination. Demo & POC Environments Run only when showing clients. Manual control for presentations. No ongoing costs between demos with quick reactivation. Training & Sandbox Schedule for training sessions. Automatic cleanup after use. Prevent runaway costs in learning environments. --- Benefits Real results, real savings Reduce AWS Bills Save 60-70% on development costs. Pay only for actual usage with predictable spending. Save Time No manual shutdowns needed. Automated operations let teams focus on development. Environmental Impact Optimize resource usage for sustainable cloud practices. Better Visibility Understand usage patterns. Identify waste and optimize architecture with data-driven decisions. --- Built for AWS Best Practices Enterprise-ready architecture Vendor-Hosted Control Plane Runless keeps the product API, scheduler, and dashboard in a multitenant SaaS account so customers do not operate their own control plane. Secure Cross-Account Access AWS access uses a dedicated customer role with least privilege and external ID guardrails. Event-Driven Runtime EventBridge-driven workers execute schedules and manual actions while pushing near real-time updates to the UI. Observability Unified status events, history tracking, and AWS-native logs support operational troubleshooting. Tenant-Scoped State Runless persists account links, schedules, inventory snapshots, and savings history per tenant. Commercial Reconciliation Linked account access is validated against subscription status before full activation. --- ## About CloudSoft Runless is developed and maintained by [CloudSoft](https://www.cloudsoft.com.pl), a professional software development company specializing in cloud solutions, serverless architectures and modern services. Visit [www.cloudsoft.com.pl](https://www.cloudsoft.com.pl) to learn more about our services and expertise in AWS cloud consulting. --- ### Small - $49 /tenant/month - Up to 3 connected AWS environments - Up to 5 users - Core automation and schedule management - Team access with owner/member roles - Cost analytics dashboard - Standard support ### Growth - $99 /tenant/month - Up to 10 connected AWS environments - Up to 20 users - Everything in Small - Expanded operational coverage - Standard support ### Custom - Custom pricing - All features in Growth - Higher environment and seat limits - Custom integrations - Priority support - Tailored packaging for your organization --- ### Does this affect production environments? No. Runless is designed for non-production environments like development, staging and QA. We recommend keeping production environments in a separate account and always on. ### How secure is Runless? Security is our top priority. Runless assumes a dedicated cross-account role with least-privilege permissions and external ID protection. All actions are logged and traceable. Your long-lived AWS credentials never leave your account. ### Can I override schedules manually? Absolutely! Every ECS service or EC2 instance can be manually turned on or off at any time, regardless of the schedule, individually or in bulk for a cluster/region. This is perfect for emergency access, late-night deployments or unexpected work sessions. ### What AWS permissions are required? Runless requires access through the onboarding role to list and describe supported resources (ECS services and EC2 instances today), update their running state, and configure EventBridge forwarding for their runtime events. Access is split into per-service grants, so you can enable only the resource types you use. The Quick Start stack provisions the role policy and trust relationship. ### How do I buy Runless? Subscribe to Runless on AWS Marketplace. Billing flows through your existing AWS invoice - no separate contract or vendor onboarding, and it counts toward committed spend and EDP. ### How long does setup take? Most teams are up and running in under 20 minutes. Launching Quick Start usually takes 10-15 minutes, and account linking plus verification in the Runless portal takes a few additional minutes. ### How is commercial access validated? After your AWS account is linked and role verification succeeds, Runless reconciles the account against your AWS Marketplace subscription status. If access is pending or inactive, the account remains visible but restricted until commercial access is active. ### How do team members get access? Runless uses tenant-level team management. Owners can invite members, assign roles, and remove users directly from the dashboard without managing a separate Cognito user pool. ### Is there a free trial? There's no free trial - plans are purchased on AWS Marketplace. If you want to prove it out on a real environment first, ask about a Pilot: a scoped engagement priced as a private offer, with terms that carry over into your ongoing subscription. ### Can I get custom terms or an annual commitment? Yes - we issue AWS Marketplace private offers for custom pricing, higher limits, and annual commitments. Reach out at contact@cloudsoft.com.pl. ### How do you calculate savings? Savings are calculated from each resource's AWS pricing (CPU/memory for ECS services, instance type for EC2) and running time. The dashboard shows actual costs saved by tracking when resources are stopped versus when they would have been running. --- ## Overview - Runless Docs (Latest) Source: https://runless.cloud/docs/latest/en # Runless Documentation Welcome to the Runless SaaS user manual. This guide explains how to onboard AWS connections, configure runtime automation, and manage team access in a multitenant control plane. ## What is Runless? Runless is a vendor-hosted runtime automation platform for non-production environments. It started with ECS and is expanding to other billable AWS resource types (RDS, EC2, Auto Scaling Groups, EKS, and more) using the same schedule-and-restore pattern. It helps you: - **Reduce AWS costs** by scheduling stop/start windows for idle resources - **Centralize control** across multiple linked AWS connections in one tenant workspace - **Operate safely** with role-based cross-account access and verification checks - **Track savings** through tenant-level dashboards and runtime history ## Getting Started Choose a topic to begin: - **[Onboarding & Account Linking](/docs/latest/en/installation)** - Link an AWS connection from Quick Start outputs - **[Updating Your Stack](/docs/latest/en/installation-update)** - Opt into new resource types as they ship - **[Team & Access Management](/docs/latest/en/user-management)** - Invite members and manage tenant roles - **[Application Manual](/docs/latest/en/application-manual)** - Use dashboards, schedules, and runtime controls - **[Account Unlink & Offboarding](/docs/latest/en/uninstallation)** - Safely remove linked accounts ## Core Concepts - **Tenant**: Your Runless workspace containing users, AWS connections, and schedules - **AWS Connection**: A linked AWS account verified through a cross-account role, with its own Quick Start stack version and per-resource-type permissions - **Commercial Status**: Subscription state used to gate full runtime operations - **Resource Type**: A category of billable AWS resource Runless can manage (for example ECS service, RDS instance). Each resource type is opt-in and requires its own IAM grant on the Quick Start stack - **Resource Rule**: A schedule (and, for resource types that need it, a restore configuration) that drives cost-saving automation for one managed resource. ECS today expresses this as a desired task count; other resource types will define their own restore configuration ## Prerequisites - Customer AWS account with ECS clusters/services to optimize - Access to the Quick Start stack outputs in the customer account - Runless account (owner or member role) ## Support For questions or issues: - **Email**: support@cloudsoft.com.pl - **Product site**: [runless.cloud](https://runless.cloud) ## Version Information This documentation targets the **latest** Runless SaaS release. --- ## Link an AWS Account - Runless Docs (Latest) Source: https://runless.cloud/docs/latest/en/installation # Onboarding and AWS Connection Linking This guide describes the Runless SaaS onboarding path. The customer-side Quick Start stack creates a scoped cross-account role, then you complete account linking in the Runless portal. ## Overview Connection onboarding has three phases: 1. **Launch Quick Start** in the customer AWS account 2. **Complete connection linking** in the Runless portal using stack outputs 3. **Verify + reconcile** role access and commercial status ## Prerequisites - An active [AWS Marketplace subscription](https://aws.amazon.com/marketplace/pp/prodview-fyqtjjmncqlbi) to Runless and access to the customer AWS account - Ability to deploy the Runless Quick Start stack - Runless account with tenant owner or member access ## Required Onboarding Values From Quick Start stack outputs: - `CustomerAwsAccountId` - `RoleArn` - `InstallationId` - `ExternalId` - `StackId` - `PortalLinkUrl` (preferred direct entry path) ## Step-by-Step Onboarding ### Launch Quick Start 1. Subscribe to Runless on [AWS Marketplace](https://aws.amazon.com/marketplace/pp/prodview-fyqtjjmncqlbi). 2. Launch the onboarding stack in the AWS account you want to manage. 3. Wait for stack completion and open the **Outputs** tab. ### Open the Runless portal 1. Open `PortalLinkUrl` from stack outputs. 2. Sign in or create your Runless account. 3. Confirm the pre-filled onboarding values. ### Complete account linking 1. Submit the onboarding form. 2. Runless stores the connection as `PENDING_VERIFICATION`. 3. Runless attempts role assumption using `ExternalId`. ### Verify and activate 1. If verification passes, connection status becomes `VERIFIED`. 2. Runless reconciles commercial access. 3. When commercial access is active, automation features are fully enabled. ## Connection Statuses | Status | Meaning | Typical action | | --- | --- | --- | | `PENDING_VERIFICATION` | Account is linked but role verification is not complete | Retry verification after IAM fixes | | `FAILED` | Verification failed | Check trust policy, external ID, and role permissions | | `VERIFIED` | Role verification succeeded | Continue with inventory/rules setup | | `PENDING_COMMERCIAL_ACCESS` | Role verified, subscription state not confirmed yet | Retry commercial access check | | `INACTIVE_COMMERCIAL_ACCESS` | Role verified, but no active product access | Update subscription status | ## Troubleshooting ### Verification fails Check: - Role trust includes the Runless product account - `sts:ExternalId` condition matches the supplied `ExternalId` - Role policy includes required ECS read + runtime actions ### Commercial access is pending or inactive Check: - Marketplace subscription for the target account - Correct product and account pairing - Retry verification from the dashboard after commercial updates ### Manual form entry If `PortalLinkUrl` is unavailable, open the registration flow from Runless and paste all required outputs manually. ## Next Steps 1. **[Team & Access Management](/docs/latest/en/user-management)** - Invite your team and assign roles 2. **[Application Manual](/docs/latest/en/application-manual)** - Configure schedules and runtime controls --- ## Updating Your Stack - Runless Docs (Latest) Source: https://runless.cloud/docs/latest/en/installation-update # Updating Your Quick Start Stack Runless is expanding beyond ECS to other AWS resource types (RDS, EC2, Auto Scaling Groups, EKS, and more). Each resource type is opt-in and requires updating the Quick Start stack in the linked AWS account. ## Why an update is needed The customer-side Quick Start stack grants the Runless cross-account role only the IAM permissions it needs. As new resource types become available, the stack adds a new `Enable` parameter (for example `EnableEcs`, `EnableRds`) for each one. Permissions for a resource type are only granted when its parameter is set to `true`. This means: - Existing permissions never change silently - you control what Runless can access. - New capabilities are invisible to your account until you update the stack and opt in. - You can disable a resource type at any time by setting its parameter back to `false` and updating the stack. ## Checking your stack version Your linked connection's card in the [dashboard](/docs/latest/en/application-manual) shows the Quick Start stack version it last reported, plus a **Stack update available** badge when a newer stack template exists. The dashboard compares the version reported at linking time against the version Runless currently ships. ## How to update Updating the stack does not affect resources Runless is already managing - in-flight schedules keep running. 1. Open the AWS CloudFormation console for the account shown on the connection card. 2. Select the Runless onboarding stack and choose **Update**. 3. Use the latest Quick Start template (same source you used to originally launch it). 4. Review the parameters: existing `Enable*` parameters keep their current values by default, so nothing you didn't opt into gets enabled by accident. Set any new `Enable*` parameter to `true` if you want to use that resource type. 5. Deploy the update and wait for `UPDATE_COMPLETE`. 6. Return to the Runless dashboard - the connection's stack version status updates the next time it verifies or refreshes inventory. ## What each Enable\* parameter grants | Parameter | Resource type | Grants | | --- | --- | --- | | `EnableEcs` | ECS services | List/describe clusters and services, update service desired count, read Application Auto Scaling targets, forward ECS state-change events | | `EnableEc2` | EC2 instances | Describe instances and instance status; start/stop instances tagged `runless:managed=true`; forward EC2 instance state-change events so the dashboard reflects console-initiated and settled (stopped/running) transitions | Additional `Enable*` parameters (`EnableRds`, `EnableAsg`, `EnableEks`, ...) are added as each resource type ships - see the [Application Manual](/docs/latest/en/application-manual) for what's currently supported. ## Next Steps 1. **[Application Manual](/docs/latest/en/application-manual)** - Configure schedules and runtime controls 2. **[Rules](/docs/latest/en/application-manual/rules)** - Review how cost-saving rules apply per resource --- ## Team & Access Management - Runless Docs (Latest) Source: https://runless.cloud/docs/latest/en/user-management # Team and Access Management Runless team access is managed inside the product tenant. You do not need to administer a separate customer-side Cognito user pool. ## Roles | Role | Permissions | | --- | --- | | **Owner** | Invite/remove members, manage AWS connections, configure runtime rules | | **Member** | Operate dashboard workflows allowed by tenant policy | ## Invite a Team Member ### Open Team tab 1. Sign in to Runless. 2. Open the dashboard and go to **Team**. ### Send invite 1. Enter user email. 2. Choose role (`Owner` or `Member`). 3. Click **Send invite**. ### Confirm activation 1. Invitee receives an email invitation. 2. After acceptance, member appears as **Active** in Team list. ## Remove a Team Member 1. Open **Team** list. 2. Find the member. 3. Click **Remove** and confirm. Runless prevents removing the last owner of a tenant. Assign another owner first if you need to transfer ownership. ## Seat Limits If your plan seat limit is reached, new invites are blocked until you: - Remove existing members, or - Upgrade your plan limits ## Access Best Practices - Keep at least two owners for operational continuity - Grant owner role only to users managing account linking or governance - Review team membership regularly ## Troubleshooting ### Invite not received - Ask the user to check spam/junk folders - Verify email address in invite form - Re-send invite from Team tab ### Member cannot access linked account actions - Verify member role and tenant membership - Confirm the linked AWS connection status is verified and commercially active ## Next Steps - **[Application Manual](/docs/latest/en/application-manual)** - Use runtime controls and schedules - **[Account Unlink & Offboarding](/docs/latest/en/uninstallation)** - Remove accounts safely when needed --- ## Getting Started - Runless Docs (Latest) Source: https://runless.cloud/docs/latest/en/application-manual # Application Manual Welcome to the Runless application manual. This guide covers tenant dashboard workflows for linked AWS accounts in the SaaS control plane. ## Overview The Runless dashboard lets you: - View linked AWS account connections and verification/commercial statuses - Load ECS inventory per linked account and cluster - Configure service and cluster schedules for cost-saving automation - Queue manual start/stop actions when needed - Track savings and runtime history ## Accessing the Application 1. Sign in at Runless using your tenant account 2. Open the dashboard 3. Select a linked AWS account and load inventory 4. Choose a cluster and manage services ## Main Sections ### AWS Connections Register, verify, and monitor linked AWS accounts with status lifecycle details. ### ECS Management Review clusters/services, configure schedules, and run manual actions. ### Savings Track realized and estimated savings by account, cluster, and service. ### Team Invite members, assign roles, and maintain tenant access controls. ## Deep Links The dashboard supports URL-based deep links: - `?cluster=` opens the dashboard with that cluster selected - `?service=:` opens a specific service configuration panel - `?clusterConfig=` opens cluster-wide configuration directly ## Detailed Guides 1. **[Clusters Management](/docs/latest/en/application-manual/clusters)** 2. **[Services Management](/docs/latest/en/application-manual/services)** 3. **[Rules Configuration](/docs/latest/en/application-manual/rules)** 4. **[Monitoring & Analytics](/docs/latest/en/application-manual/monitoring)** --- ## Clusters - Runless Docs (Latest) Source: https://runless.cloud/docs/latest/en/application-manual/clusters # Clusters Management Learn how to view, monitor, and manage ECS clusters for a linked AWS connection in your Runless tenant. ## Overview Clusters are managed directly from the dashboard after you select a linked AWS connection. For a selected account and cluster, you see: - **Cluster Details Panel** - cost and task metrics for the active cluster - **Cluster Actions Card** - bulk start/stop controls and cluster-wide schedule configuration - **Services Table** - all services in the cluster with per-service actions ## Selecting an AWS Account and Cluster 1. Sign in to Runless 2. Select the linked **AWS Account** connection 3. Load or refresh inventory when needed 4. Use the **Select Cluster** dropdown and choose a cluster The dashboard updates immediately with metrics and services for the selected cluster. ## Cluster Details Panel | Metric | Description | | ------------------------------ | ---------------------------------------------------- | | **Services** | Total number of ECS services in the selected cluster | | **Total Tasks** | Combined desired task count across services | | **Cost per Hour** | Estimated current hourly cost for running tasks | | **Gross Monthly Cost** | Estimated monthly cost without schedule savings | | **Estimated Savings** | Projected monthly savings from configured schedules | | **Net Monthly Cost** | Gross monthly cost minus projected savings | | **Current Savings (Realized)** | Savings already realized from stopped runtime | ## Cluster Actions Card The **Cluster Actions** card provides bulk controls for the selected cluster. ### Cluster Status Badge - **ALL RUNNING** - every service is running - **ALL STOPPED** - every service is stopped - **MIXED** - service states differ across the cluster ### Bulk Actions | Button | When enabled | Effect | | ------------- | ---------------------------------- | ---------------------------------------------- | | **Start All** | Any service is stopped or unknown | Starts stopped/unknown services in the cluster | | **Stop All** | Any service is running or starting | Stops running/starting services in the cluster | | **Configure** | Always | Opens the cluster-wide schedule panel | Both **Start All** and **Stop All** require confirmation. Stopping all services affects availability for the selected cluster. Use this pattern for non-production environments unless you have explicit production controls. ## Cluster Configuration Panel Click **Configure** to apply one shared schedule to all services in the cluster. ### Open configuration In the **Cluster Actions** card, click **Configure**. ### Review cluster data Confirm service count, task totals, and current cost metrics. ### Configure cost-saving schedule 1. Enable **Cost Saving** 2. Set **Startup Time (UTC)** and **Shutdown Time (UTC)** 3. Select active **Days of the week** ### Save Click **Save** to apply the schedule to all services in the selected cluster. Cluster-wide configuration applies one schedule pattern to all services while preserving each service baseline task expectations. ## Services Table | Column | Description | | ---------------- | ---------------------------------------------------------------------------------- | | **Service Name** | ECS service name and status dot. A **Manual** badge means no active schedule rule. | | **Tasks** | Running versus expected tasks, with autoscaling range when available | | **Resources** | vCPU, memory, and launch type metadata | | **Cost Saving** | Estimated savings indicator when cost-saving is enabled | | **Monthly Cost** | Estimated monthly cost for the service | | **Actions** | **Start** or **Stop** based on current status | ### Service Status Dot Colors - **Green** - Running - **Yellow** - Starting - **Red** - Stopped or stopping - **Gray** - Unknown ### Start or Stop an Individual Service 1. Locate the service row 2. Click **Start** or **Stop** 3. Confirm the action Click a service name to open full service controls in the [Services guide](/docs/latest/en/application-manual/services). ## Inventory Refresh and Cluster Discovery Runless reads cluster data through the linked AWS connection and refreshes inventory after relevant actions. Use manual inventory refresh when data appears stale. ## Best Practices - Keep production and non-production clusters separated - Start with cluster-wide schedules, then override at service level only when needed - Review cluster-level savings weekly and tune schedules monthly ## Troubleshooting ### Cluster does not appear 1. Verify the AWS connection is linked and verified 2. Refresh inventory for the selected connection 3. Confirm the cluster has ECS services in the selected region ### Status or task counts look stale 1. Run manual inventory refresh 2. Retry after a short delay following runtime actions 3. Check control-plane logs if updates remain inconsistent ### Cluster rules are not executing 1. Confirm cost-saving is enabled for the cluster/services 2. Verify connection remains commercially active 3. Check recent runtime history and notifications for failures ## Next Steps - **[Services Management](/docs/latest/en/application-manual/services)** - Configure per-service runtime behavior - **[Rules Configuration](/docs/latest/en/application-manual/rules)** - Manage schedule semantics - **[Monitoring & Analytics](/docs/latest/en/application-manual/monitoring)** - Track savings and execution results --- ## Services - Runless Docs (Latest) Source: https://runless.cloud/docs/latest/en/application-manual/services # Services Management Manage individual ECS services for a linked AWS connection: inspect state, queue manual actions, and configure cost-saving schedules. ## Overview From the dashboard, select a linked AWS connection and cluster, then click a service name to open the **Service Configuration Panel**. The panel includes: - Service metadata (launch type, architecture, task and cost details) - Service control (current status and manual start/stop actions) - **Configuration** tab (cost-saving rule management) - **History** tab (shutdown/startup records and savings) ## Viewing Services 1. Select AWS account connection 2. Select cluster 3. Find a service in the **Services Table** 4. Click service name to open detailed controls ### Services Table Columns | Column | Description | | ---------------- | --------------------------------------------------------------------------- | | **Service Name** | Service name with status dot; **Manual** badge indicates no active schedule | | **Tasks** | Running versus expected task count with autoscaling range when available | | **Resources** | vCPU, memory, and launch type | | **Cost Saving** | Estimated savings badge when rule is enabled | | **Monthly Cost** | Monthly cost estimate for current configuration | | **Actions** | **Start** and **Stop** buttons based on status | ## Service Configuration Panel ### Service Details Card | Field | Description | | --------------------- | --------------------------------------------------- | | **Launch Type** | Fargate or EC2 | | **Operating System** | Runtime OS from task definition | | **Architecture** | CPU architecture such as X86_64 or ARM64 | | **Task Count** | Desired task count with autoscaling min-max context | | **vCPU per Task** | vCPU allocation per task | | **Memory per Task** | Memory allocation per task | | **Cost per Hour** | Estimated hourly runtime cost | | **Est. Monthly Cost** | Estimated monthly runtime cost | ### Service Control Card Status colors: - **Green** - Running - **Yellow** - Starting - **Red** - Stopped or stopping - **Gray** - Unknown A **Manual** badge means no active cost-saving rule is stored for this service. #### Start Service - Enabled when service is stopped or unknown - Queues a manual startup action - Restores service to configured expected task count Starting a service can take several minutes depending on image pull and task startup time. #### Stop Service - Enabled when service is running or starting - Queues a manual stop action - Scales desired count to zero Stop actions affect service availability immediately. Use carefully in shared clusters. ## Configuration Tab ### Enable Cost Saving Turn on **Enable Cost Saving** to store and enforce a schedule for this service. When disabled, the service remains manually managed and schedule automation is inactive. ### Desired Task Count Set the desired task count to restore at startup. Allowed values follow autoscaling constraints. ### Schedule Fields | Field | Description | | ----------------------- | -------------------------------- | | **Startup Time (UTC)** | Daily time to start the service | | **Shutdown Time (UTC)** | Daily time to stop the service | | **Days** | Active weekdays for the schedule | The UI validates and previews cron expressions behind the schedule. ### Estimated Monthly Savings Savings estimate updates as schedule values change, based on expected runtime reduction and task cost profile. ### Save or Clear - Click **Save** to persist enablement, desired task count, and schedule - Click **Clear rule** to remove automation for this service Only one schedule rule is stored per service. For broad consistency, use cluster-wide schedule application first. ## History Tab The **History** tab tracks shutdown/startup cycles. | Column | Description | | ------------------ | ----------------------------------------------------- | | **Shutdown** | Stop timestamp and trigger type (scheduled or manual) | | **Startup** | Start timestamp and trigger type | | **Saved Duration** | Total downtime for the cycle | | **Amount Saved** | Estimated savings for that downtime period | ## Troubleshooting ### Service will not start - Check ECS capacity, networking, and task definition health - Confirm the linked AWS connection remains verified - Review runtime action errors in logs/history ### Service stops unexpectedly - Check active schedule rule - Review manual action history - Inspect autoscaling interactions ## Next Steps - **[Rules Configuration](/docs/latest/en/application-manual/rules)** - Fine-tune schedule behavior - **[Monitoring & Analytics](/docs/latest/en/application-manual/monitoring)** - Track execution and savings trends --- ## EC2 Instances - Runless Docs (Latest) Source: https://runless.cloud/docs/latest/en/application-manual/ec2-instances # EC2 Instances Schedule individual EC2 instances to stop overnight and on weekends, then start again before working hours - the same remember-and-restore model Runless uses for ECS, applied to plain instances. ## Overview Select **EC2** in the Resources tab to list the instances Runless can see across your enabled regions. Each row shows the instance name (from its `Name` tag), its id and region, the on-demand cost per hour, the projected monthly savings once a schedule is attached, and whether a schedule is currently configured. Stopping an instance stops billing for its compute. Starting it again restores the same instance - its instance id, private IP, and EBS volumes are preserved. EBS storage still bills while stopped Stopping an EC2 instance stops the hourly compute charge, but attached EBS volumes continue to bill for storage. Projected savings shown in the dashboard cover instance compute only. ## Requirements For Runless to stop and start an instance, two things must be true: 1. **The EC2 permission is enabled on your stack.** The Quick Start stack grants EC2 access behind the `EnableEc2` parameter (on by default). See [Updating Your Stack](/installation-update). 2. **The instance is tagged `runless:managed=true`.** Stop/Start permissions are scoped to this tag, so Runless can never act on an instance you have not explicitly opted in. Discovery still _lists_ untagged instances so you can find them, but they appear greyed-out until tagged. ```hcl # Terraform example resource "aws_instance" "dev_box" { # ... tags = { Name = "dev-box" "runless:managed" = "true" } } ``` ## Which instances can be scheduled Runless lists every instance in your enabled regions but marks some as not schedulable, with the reason shown inline: | Instance | Schedulable? | Why | | --- | --- | --- | | On-demand, EBS-backed, tagged `runless:managed=true` | Yes | Clean stop/start preserves the instance | | Missing the `runless:managed` tag | No | Tag it to opt in | | Auto Scaling Group member (`aws:autoscaling:groupName` tag) | No | Schedule the group instead (coming soon) | | Spot instance | No | Spot instances can't be stopped and resumed on a schedule | | Instance-store-backed | No | Data on instance-store volumes is lost on stop | ## Attaching a schedule Expand a schedulable instance and pick the active days and the startup/shutdown times (in UTC). Runless creates two schedules per rule - one to stop, one to start - and shows the projected monthly savings based on the instance's on-demand price and the idle window. To schedule many instances at once, select a region and use the **Region-wide schedule** panel to apply one schedule to every schedulable instance in that region. A later per-instance edit overrides just that instance; re-applying the region schedule overwrites them all. Stopping and starting take a moment EC2 stop and start are not instantaneous. An instance moves through astopping state before it reaches{' '} stopped, and through pending before running. The dashboard updates live as each transition happens - including instances you stop or start directly in the AWS console - so you don't need to refresh the list to see the settled state. See [Rules](/application-manual/rules) for how schedule windows and time zones work, and [Monitoring & Savings](/application-manual/monitoring) for how realized savings are tracked. --- ## Rules - Runless Docs (Latest) Source: https://runless.cloud/docs/latest/en/application-manual/rules # Rules Configuration Configure time-based schedules that automate ECS service runtime for linked AWS connections. ## Overview Rules tell Runless when to stop and restart services. They help you: - Reduce idle runtime in non-production environments - Standardize start/stop windows across teams - Keep manual override capability when needed Rules are configured inside service or cluster configuration panels. There is no separate Rules screen. ## Rule Model Runless uses one rule model per service: a daily schedule with active days. | Field | Description | | ----------------------- | ----------------------------------------- | | **Startup Time (UTC)** | Time of day to start the service | | **Shutdown Time (UTC)** | Time of day to stop the service | | **Days** | Days of week when schedule is active | | **Desired Task Count** | Task count restored during startup window | Each service stores one active rule at a time. ## Create a Service Rule ### Open service panel From dashboard services table, click the service name. ### Open Configuration tab Go to **Configuration** and enable cost saving. ### Configure values 1. Set **Desired Task Count** 2. Set **Startup Time (UTC)** 3. Set **Shutdown Time (UTC)** 4. Select active **Days** ### Review estimate and save Check projected monthly savings and click **Save**. ## Create a Cluster-Wide Rule To apply one schedule across every service in a cluster at once: 1. Select the cluster and open the **Cluster-wide schedule** panel above the service list 2. Choose **Configure schedule**, define the active days and startup/shutdown times 3. Choose **Apply to all services** The same schedule is written to every schedulable service in the cluster. Afterwards you can still open an individual service and give it a different schedule - that per-service edit overwrites only that service. Re-applying the cluster-wide schedule overwrites **all** services again (including any you tuned individually), so apply the cluster baseline first and customize exceptions afterwards. If services currently have different schedules, the panel says so and an apply overwrites them all. EC2 offers the equivalent at the region level: pick a region and use the **Region-wide schedule** panel to apply one schedule to every schedulable instance in that region. ## Edit or Remove a Rule ### Edit 1. Open service or cluster configuration 2. Adjust schedule values 3. Save changes ### Remove 1. Open configuration panel 2. Use **Clear rule** or **Remove** action 3. Save changes Removing a rule does not automatically restart stopped services. Use manual start when immediate restoration is required. ## Execution Model 1. Rule configuration is stored in the Runless tenant control plane 2. Scheduler/worker flows trigger runtime actions at configured times 3. Workers assume the linked account role and update ECS service desired count 4. Status and history updates are written back to dashboard data ## Best Practices ### Keep schedules in UTC Define schedules in UTC and review daylight saving impacts for your operating region. ### Start from cluster defaults Apply cluster-wide schedules first, then customize exceptions at service level. ### Validate desired task count Ensure startup task count aligns with autoscaling bounds and service dependencies. ### Test before wider rollout Validate new schedules on dev/staging workloads before applying broadly. ## Troubleshooting ### Save fails Check: 1. Startup and shutdown values are valid and different 2. Desired task count is within allowed range 3. Connection is verified and commercially active ### Rules do not execute as expected Check: 1. Rule is still enabled 2. Selected days and UTC times are correct 3. Runtime history contains scheduler or action errors ## Next Steps - **[Services Management](/docs/latest/en/application-manual/services)** - Manage per-service runtime controls - **[Monitoring & Analytics](/docs/latest/en/application-manual/monitoring)** - Measure rule effectiveness --- ## Monitoring - Runless Docs (Latest) Source: https://runless.cloud/docs/latest/en/application-manual/monitoring # Monitoring & Savings Track runtime state, action history, and cost savings across linked AWS connections in your Runless tenant. ## Overview Monitoring data is available directly in dashboard workflows: - **Header savings** for tenant-level realized savings - **Notifications** for recent service state changes - **Service history** for per-service shutdown/startup cycles - **Cluster cost panels** for projected versus realized savings context ## Tenant Savings (Header) The top header displays total realized savings for your tenant based on recorded runtime downtime across linked accounts. ## Notifications The notification bell shows recent service status events with service identity, status, and timestamp. These updates are delivered as real-time control-plane events to active dashboard sessions. ## Service Runtime History To inspect one service: 1. Select AWS account and cluster 2. Open service configuration panel 3. Open **History** tab | Column | Description | | ------------------ | -------------------------------------------------- | | **Shutdown** | Stop timestamp and trigger type (scheduled/manual) | | **Startup** | Start timestamp and trigger type | | **Saved Duration** | Downtime length for the cycle | | **Amount Saved** | Estimated cost saved during that downtime | ## Savings Calculation Runless estimates per-cycle savings using downtime, task cost profile, and restored task count: ```text Amount Saved = Hours Stopped x Cost per Task per Hour x Desired Task Count ``` Projected monthly savings in rule editors use the same pricing model with schedule-based runtime assumptions. Typical Outcomes Teams commonly save 40-60% in non-production ECS environments when schedules are aligned to working hours and weekend inactivity. ## Cluster Cost Metrics For the selected cluster, the dashboard summarizes: - Current hourly cost - Gross monthly cost (without savings) - Estimated monthly savings from active schedules - Net monthly cost - Realized savings to date ## Operational Troubleshooting If monitoring values look incorrect: 1. Refresh inventory and service history for the connection 2. Confirm the connection remains verified and commercially active 3. Review recent runtime action outcomes in history and notifications 4. Check backend logs for persistent API or runtime failures ## External Logs Runless does not include a full in-app raw log viewer. For deep diagnostics, inspect AWS logs available to your operations environment, including control-plane and runtime execution logs. --- ## Account Unlink & Offboarding - Runless Docs (Latest) Source: https://runless.cloud/docs/latest/en/uninstallation # Account Unlink and Offboarding Important In the SaaS model, offboarding usually means unlinking an AWS connection from your tenant. This does not delete your ECS clusters or services. ## Offboarding Options 1. **Unlink account only** - Remove connection from Runless while keeping customer onboarding stack in AWS 2. **Full offboarding** - Unlink account, then delete the customer Quick Start stack if no longer needed ## Before You Start - Export required reports (savings/history) if needed for audit - Confirm service desired counts for workloads that must stay running - Notify tenant owners and operators about offboarding window ## Unlink an AWS Connection ### Open connection details 1. Sign in to Runless. 2. Open dashboard and select the AWS connection. ### Remove connection 1. Use the unlink/remove action in account controls. 2. Confirm the action. 3. Verify the connection no longer appears in the active list. ### Validate workloads 1. Open AWS Console in customer account. 2. Confirm ECS services are in intended state. ## Optional: Remove Quick Start Stack If you want to remove the customer-side onboarding role: 1. Open CloudFormation in the customer account 2. Locate the Runless onboarding stack 3. Delete the stack 4. Confirm the role is removed Deleting the onboarding stack prevents further Runless access to that account until a new stack is deployed and linked again. ## Troubleshooting ### Connection cannot be removed - Verify you are an owner in the tenant - Ensure no active workflow depends on this account - Retry after refreshing connection state ### Account still shows as active - Refresh dashboard data - Confirm removal mutation completed successfully - Check for duplicate connections to the same account ID ## Post-Offboarding Checklist - Access role removed or disabled in customer account - No pending Runless actions for the account - Team informed of completion - Required reports exported and archived