By the end of their first quarter, they had spent more on infrastructure than they had earned in revenue. Except, they didn’t have millions of users. They had a few hundred. Yet their cloud bill was climbing north of $1,000 per month. Before they had a chance to iterate on their product-market fit, they were drowning in infrastructure costs. Within a year, they shut down.

This is a common story — that plays out in different variations across the startup world. Founders and engineers often over-engineer their infrastructure based on hypothetical future needs, rather than present realities.

As a DevOps and infrastructure engineer, I have repeatedly seen this mistake: teams spend excessive time and resources designing for massive scalability when they haven’t even validated their core business model. In this article, I will share important lessons I’ve learned throughout my journey and how to strike the right balance between scalability and efficiency.

The truth is, you don’t need to scale until your business demands it.

The High Cost of Premature Scaling

AWS, GCP, and Azure provide powerful infrastructure solutions, but they come at a steep price. When teams configure auto-scaling groups, distribute workloads across multiple availability zones, and implement advanced caching strategies before their traffic justifies it, they introduce unnecessary complexity and cost.

Where the Costs Add Up

1. Cloud Providers Are Expensive: Distributed architectures come with increased networking, storage, and data transfer costs.

2. Overprovisioned Resources Drain Budget: Teams often allocate excessive computing power without fully utilizing it, leading to wasted spend.

3. Operational Complexity Kills Agility: Managing a multi-cloud, multi-region setup requires dedicated DevOps expertise, adding overhead.

Scaling Strategies

Picking the Right Approach

Scaling is a fundamental concept in software architecture, referring to a system’s ability to handle increased load. Scaling isn’t one-size-fits-all. Businesses need to choose the right strategy based on demand — application specific needs and growth patterns. Here are the three main approaches:

• Vertical Scaling (Scaling Up): Enhancing the capacity of a single server by adding more resources, such as CPU or RAM. It’s like upgrading a computer to make it more powerful.

• Horizontal Scaling (Scaling Out): Adding more servers to distribute the load. This approach increases capacity by expanding the number of machines working together.

• Diagonal Scaling (A Balanced Approach): Diagonal scaling is a flexible approach that combines both vertical and horizontal scaling, adjusting dynamically based on current demand. Instead of choosing one strategy upfront, it starts with vertical scaling — adding more CPU, memory, or storage to a single machine until it reaches its limit. Once further growth is needed, it shifts to horizontal scaling by distributing workloads across multiple instances. For example, a business might begin by upgrading its database server, but as traffic grows, it can introduce read replicas and load balancing to manage increasing queries efficiently.

The key advantage of diagonal scaling is adaptability — it allows infrastructure to grow when demand rises and scale down when demand drops, ensuring cost-efficiency without unnecessary complexity.

A Smarter Approach

When to Use the Right Scaling Strategy

Instead of over-engineering infrastructure and blindly deploying a distributed system from the beginning, companies should start simple and scale incrementally, teams should optimize their architecture based on actual usage patterns:

1. Use Vertical Scaling First: If your application is CPU/memory-bound and traffic is predictable, upgrading to a larger instance is usually the simplest and most cost-effective solution.

2. Introduce Horizontal Scaling When Needed: If you’re hitting consistent performance bottlenecks due to concurrent traffic spikes, then adding more instances makes sense.

3. Monitor Before Scaling: Performance bottlenecks should be analyzed first — sometimes caching, query optimization, or asynchronous processing can eliminate the need for immediate scaling.

For applications with fewer than 1,000 monthly users, a monolithic architecture with vertical scaling is often one of the best approach.

Why Monoliths Work Better at Early Stages

Many startups jump straight into microservices, thinking it’s the modern way to build software. However, microservices introduce communication overhead, deployment complexity, and operational challenges. A well-structured monolith is often easier and cheaper to maintain early on as it provides:

1. Lower Infrastructure Cost: A single well-optimized instance is cheaper than running multiple small instances with distributed overhead.

2. Simplified Debugging & Maintenance: Fewer moving parts mean fewer things breaking at scale.

3. Easier to Iterate: Early-stage applications require rapid development cycles, not excessive infrastructure.

Practical Steps to Scale the Right Way

1. Keep it Monolithic Initially: Until you hit scale bottlenecks, avoid microservices and distributed patterns.

2. Optimize Before Scaling: Improve database queries, implement caching (Redis, Memcached), and optimize code efficiency before provisioning more resources.

3. Benchmark Your Limits: Use load testing to define at what threshold your infrastructure needs to scale.

“But I Don’t Want to Configure Things Twice!”

A common argument against starting small is that reconfiguring for scale later requires extra work. However, this thinking ignores two critical realities:

1. Your Scaling Needs Will Evolve Unpredictably: Designing prematurely for a million users results in unnecessary complexity.

2. Modern Migration Is Easier Than Ever: Tools like Terraform, Kubernetes, and cloud-native databases simplify infrastructure changes.

Investing in massive scalability before demand exists is like renting a stadium before you’ve formed a local football team.

Is Serverless Really Cost-Effective?

Serverless computing is often marketed as an affordable way to scale, but poor configurations can lead to unexpected costs. Misconfigured AWS Lambda, Firebase, or Vercel functions have resulted in five-figure invoices due to:

• Execution Duration Costs: Poorly optimized functions that run longer than necessary drive up costs.

• Concurrency Limits and Scaling Behavior: Auto-scaling adds more instances, each incurring additional costs.

• Networking Costs: Frequent external database calls lead to excessive cross-region networking charges.

Serverless isn’t inherently bad, but it requires careful tuning. It’s not always the cheapest solution, especially when running continuously.

The Importance of Building for Scalability — Without Prematurely Scaling

While premature scaling is a mistake, engineers should still design applications for future scalability without introducing unnecessary overhead.

How to Design for Future Scaling

• Decouple Core Logic: Structuring business logic modularly makes migrating to microservices easier.

• Choose Databases That Scale: PostgreSQL, MySQL, and other relational databases can handle significant scale if architected properly with indexing, replication, and partitioning strategies.

• Implement Caching from Day One: Using a caching layer like Redis significantly reduces the need for excessive scaling by offloading repeated queries.

• Use Feature Flags and Modular Deployment: This enables incremental migrations without massive rework.

• Avoid Cloud Vendor Lock-in: Open standards for databases, messaging queues, and storage provide long-term flexibility.

When to Actually Scale

There is a right time to move beyond vertical scaling and invest in horizontal scaling, distributed databases, and containerized workloads.

That time comes when:

• Traffic consistently exceeds 10,000+ monthly users, and performance bottlenecks arise despite optimizations.

• A single server is no longer enough due to CPU/memory constraints, even after vertical scaling.

• Your team requires independent deployments, and the monolith slows down development velocity.

• Your business model is validated, and you need high availability guarantees for paying customers.

Conclusion: Scale When Your Business Scales

Before designing for millions of users, ask yourself: Do I even have a thousand yet?

Many startups fail because they focus on enterprise-scale infrastructure before validating their business model.

So, as a business, what is the best infrastructure that won’t cost a lot but can scale when demand rises or falls?

The answer lies in diagonal scaling because the best infrastructure balances cost and scalability:

• Start lean with minimal but efficient resources.

• Optimize vertically first — improve performance before adding more machines.

• Scale horizontally only when necessary.

• Use automation to scale dynamically, avoiding unnecessary costs.

Scaling should be a response to growth, not a prediction of it. Businesses that scale too soon waste money and slow down development. The key is to build infrastructure based on real demand, not future assumptions.

By balancing lean infrastructure with scalable software design and actual business growth, engineers and startups can manage costs effectively while positioning themselves for future success.

While Caddy can handle automatic certificate management with Let’s Encrypt, there are situations where you may need to use a certificate provided by a third-party CA.

We’ll demonstrate how to deploy and configure this type of certificate with Caddy, including the necessary steps to ensure it works correctly.

We’ll automate the setup using Ansible ( A popular automation tool for configuring systems and deploying applications with simple, human-readable YAML files ) to simplify and streamline the process for production environments.

Prerequisites

Before you begin, ensure that you have:

1. A valid SSL/TLS certificate and corresponding private key from your CA.

2. Ansible installed for automation.

3. Root or sudo privileges on the server to install packages and modify system configurations.

Step 1: Preparing Your Certificate Files

When you receive an SSL certificate from a commercial Certificate Authority, it often consists of multiple files, such as:

1. The leaf certificate (your server’s certificate) — usually ends with .crt or .pem

2. The intermediate certificate (which bridges the trust between your leaf certificate and the root certificate) — ends with .crt or .pem

3. The private key associated with the leaf certificate — usually ends with .key

Sometimes these certificates are provided separately, and sometimes in a single file (full chain). In most cases, the leaf certificate needs to be combined with the intermediate certificate to form the full certificate chain. This ensures that browsers and other clients can validate the entire trust path, from the root CA to your leaf certificate.

Step 2: Setting Up Ansible to Automate the Configuration

For this guide, we’ll use Ansible to automate the deployment of your SSL certificate onto the Caddy server. The Ansible playbook will copy your certificate files, concatenate the leaf and intermediate certificates (if needed), and configure Caddy to use them.

Here is an example Ansible Playbook that automates the process of installing dependencies, configuring Caddy, and deploying the certificate:

- hosts: all
  become: yes
  tasks:
    - name: Update apt packages
      become: true
      apt:
        update_cache: yes

    - name: Install Caddy and fail2ban
      become: true
      apt:
        pkg:
          - caddy
          - fail2ban

    - name: Copy server certificate file (example.com.crt)
      copy:
        src: ../templates/example.com.crt
        dest: /etc/ssl/certs/example.com.crt
        mode: ‘0644'

    - name: Set correct ownership for the certificate file
      file:
        path: /etc/ssl/certs/example.com.crt
        owner: caddy
        group: caddy
        mode: ‘0644'

    - name: Copy intermediate certificate (DigiCertCA.crt)
      copy:
        src: ../templates/DigiCertCA.crt
        dest: /etc/ssl/certs/DigiCertCA.crt
        mode: ‘0644'

    - name: Set correct ownership for the intermediate certificate
      file:
        path: /etc/ssl/certs/DigiCertCA.crt
        owner: caddy
        group: caddy
        mode: ‘0644'

    - name: Concatenate server certificate and intermediate certificate to form a full chain
      shell: "cat /etc/ssl/certs/example.com.crt /etc/ssl/certs/DigiCertCA.crt > /etc/ssl/certs/example.com_fullchain.crt"
      args:
        creates: /etc/ssl/certs/example.com_fullchain.crt

    - name: Copy private key file (example.com.key)
      copy:
        src: ../templates/example.com.key
        dest: /etc/ssl/private/example.com.key
        mode: ‘0600'

    - name: Set correct ownership for the private key file
      file:
        path: /etc/ssl/private/example.com.key
        owner: caddy
        group: caddy
        mode: ‘0600'

    - name: Set correct permissions for the /etc/ssl/private directory
      file:
        path: /etc/ssl/private
        owner: caddy
        group: caddy
        mode: ‘0750'

    - name: Copy Caddy configuration file
      template:
        src: ../templates/Caddyfile
        dest: /etc/caddy/Caddyfile

    - name: Format Caddyfile
      ansible.builtin.shell: /usr/bin/caddy fmt --overwrite /etc/caddy/Caddyfile

    - name: Reload Caddy service to apply changes
      systemd:
        name: caddy
        state: reloaded

Step 3: Explanation of Key Steps

1. Copying Certificate Files
After the installation, we begin by copying the necessary certificate files to their proper locations. These files typically include:

• Leaf Certificate (example.com.crt): This is the public certificate issued for your domain.

• Intermediate Certificate (DigiCertCA.crt): This bridges the trust between your leaf certificate and the root certificate.

• Private Key (example.com.key): This is the private key that matches your leaf certificate.

These files are placed in the appropriate directories (/etc/ssl/certs and /etc/ssl/private) with correct file permissions to ensure proper access control. The playbook will set ownership to the caddy user, which is important for security.

2. Concatenating the Full Chain
In most cases, the leaf certificate needs to be combined with the intermediate certificate to form a full certificate chain. This ensures that clients can trace the certificate back to a trusted root authority.

Here’s the command used to concatenate the certificates:

cat /etc/ssl/certs/example.com.crt /etc/ssl/certs/DigiCertCA.crt > /etc/ssl/certs/example.com_fullchain.crt

The full chain includes the leaf certificate first, followed by the intermediate certificate. This order is important because it ensures the correct certificate trust path.

3. Configuring Caddy with the Certificates
Next, the template Caddyfile is configured to use the full certificate chain and the private key. The Caddyfile is a simple configuration file where we specify the certificate locations.

Here’s the relevant section in the Caddyfile:

example.com {
    tls /etc/ssl/certs/example.com_fullchain.crt /etc/ssl/private/example.com.key
    reverse_proxy localhost:8080
}

The tls directive tells Caddy to use the full chain certificate and the private key for SSL/TLS encryption. The reverse_proxy directive forwards traffic to your application running on localhost:8080.

4. Reloading Caddy

Finally, the playbook reloads the Caddy service using systemd to apply the new configuration and certificate changes:

- name: Reload Caddy service to apply changes
  systemd:
    name: caddy
    state: reloaded

Step 4: Running the Playbook

To apply the changes, you’ll run the Ansible playbook on your server with the following command:

ansible-playbook -i your_inventory_file configure_caddy.yml

This will automate the entire process, including copying the certificate files, setting up Caddy, and reloading the service.

Step 5: Validation via Command Line

After deploying the certificate using Ansible, you can use the openssl command to validate the expiration of the SSL certificate from your local machine or a remote server:

1. Using openssl to Check SSL Expiration:

This command will connect to your server and display the expiration date of the SSL certificate:

openssl s_client -connect yourdomain.com:443 -servername yourdomain.com </dev/null 2>/dev/null | openssl x509 -noout -enddate

Output: The command will return a line like this:

notAfter=Dec 31 23:59:59 2024 GMT

Conclusion

In this article, we’ve demonstrated how to configure Caddy with an external SSL/TLS certificate from a commercial Certificate Authority. Using Ansible, we’ve automated copying the certificate files, concatenating the full chain, and configuring Caddy to use the certificate for encrypted communication. By following this guide, you can ensure that your Caddy server is securely configured with external certificates, making it ready for production with minimal manual intervention.

By automating this process, you can easily scale and maintain secure configurations for multiple servers, saving you time and reducing the chance of errors.

Irene Ufia is a software engineer specializing in DevSecOps (Blockchain Infrastructure).

Follow me for insights and technical tips: LinkedIn | Github