On 11 June 2025, just two days after starting development, we deployed our lettings management platform to production on Heroku. This wasn't premature optimisation—it was a deliberate strategy to ensure the application could run reliably in the real world from the earliest possible moment.
For letting agencies evaluating property management software, the hosting platform is rarely the first question. You're more concerned with features, integrations, and user experience. But the infrastructure decision has cascading implications for costs, reliability, security, and how quickly new features can reach your team. This article explains why we chose Heroku and what it means in practice.
What Your Team Will Notice
The honest answer is: your team won't notice the hosting platform at all, which is precisely the point. They'll notice that the application loads quickly, that updates happen smoothly without downtime, and that the system remains accessible whether your office is in London, Leeds, or Lisburn.
When an update goes live—whether it's a bug fix, a new feature, or a security patch—there's no "maintenance window" requiring everyone to log out at midnight. Deployments happen seamlessly in the background. One moment the old version is serving requests, the next moment the new version takes over, typically with zero dropped connections.
If traffic spikes unexpectedly (say, after a property listing goes viral on social media or during a regional housing shortage), the platform scales automatically. Heroku can spin up additional web servers (called "dynos" in their terminology) to handle the load, then scale back down during quieter periods. Your team never experiences slowdowns, and you don't pay for idle capacity.
The HTTPS encryption that secures all connections between browsers and servers is automatic. Heroku provisions SSL certificates through Let's Encrypt, renews them before expiry, and handles the technical configuration. For agencies handling sensitive tenant data, rental agreements, and financial records, this isn't optional—it's a legal and ethical requirement that Heroku makes effortless.
Under the Bonnet: Heroku's Architecture
Heroku is a platform-as-a-service (PaaS), which means it sits between traditional server hosting and fully managed SaaS products. You provide application code (in our case, Rails); Heroku handles everything else: operating system patches, Ruby runtime updates, PostgreSQL database management, log aggregation, and traffic routing.
The initial deployment configuration modified config/database.yml to use Heroku's DATABASE_URL environment variable:
# config/database.yml
production:
<<: *default
url: <%= ENV['DATABASE_URL'] %>
pool: <%= ENV.fetch("RAILS_MAX_THREADS") { 5 } %>
This single line of configuration replaces dozens of lines of manual database setup. When you create a Heroku application, it provisions a PostgreSQL database automatically and injects credentials via environment variables. If Heroku rotates those credentials (which happens periodically for security), the application adapts automatically without code changes.
We also specified the Ruby version explicitly in the Gemfile:
# Gemfile
ruby "3.2.3"
This ensures Heroku uses the exact Ruby version we've tested locally. When we're ready to upgrade Ruby (which we did to 3.2.9 in Week 35), we change this single line, run the test suite, and deploy. Heroku handles downloading, installing, and configuring the new runtime.
The Deployment Workflow
Deploying to Heroku uses Git, which means the deployment process integrates seamlessly with version control:
git push heroku main
That's it. Heroku detects that this is a Rails application, installs Ruby dependencies (via Bundler), compiles assets (JavaScript and CSS), runs database migrations, and starts the application servers. The entire process typically completes in 30–60 seconds.
Compare this to traditional server deployments:
- SSH into the server
- Pull the latest code
- Install dependencies
- Precompile assets
- Run migrations
- Restart application servers
- Hope nothing broke
With Heroku, steps 2–7 are automated, tested, and repeatable. If a deployment fails (say, a migration has a syntax error), Heroku aborts the deployment and keeps the old version running. Your team never experiences a broken application.
Database Management: PostgreSQL Without the Complexity
Heroku provisions PostgreSQL databases that are production-ready from day one:
- Automated backups: Daily backups retained for a week (longer retention available in higher tiers)
- Point-in-time recovery: Restore to any moment in the past 4 days
- Connection pooling: Efficiently manages database connections even under high load
- Monitoring: Built-in dashboards showing query performance, connection counts, and disk usage
Our initial configuration included a subtle but important fix for Action Cable:
# config/cable.yml
production:
adapter: postgresql
# Uses the primary database for WebSocket persistence
Action Cable powers real-time features like live notifications and collaborative editing. Many tutorials recommend using Redis for this, which is excellent for high-traffic scenarios but adds operational complexity. Starting with PostgreSQL meant one less service to manage, monitor, and pay for. When the application scales to the point where Redis makes sense, migrating is straightforward—but many applications never reach that threshold.
Managing Credentials Securely
Rails 8 introduced improvements to credentials management, and we configured these for Heroku immediately:
# config/application.rb
config.credentials.content_path =
Rails.root.join("config", "credentials.yml.enc")
The credentials.yml.enc file stores secrets (API keys, database passwords, etc.) encrypted with a master key. In development, the master key lives in config/master.key. In production on Heroku, it's stored as the RAILS_MASTER_KEY environment variable.
This approach means sensitive credentials never appear in Git history, never get accidentally committed to public repositories, and can't be viewed even by people with access to the Heroku dashboard unless they also have the master key. For agencies subject to GDPR, this kind of secrets management isn't optional—it's a requirement.
Cost Considerations for Letting Agencies
Heroku's pricing is transparent and predictable, which matters for budgeting:
Development/Staging:
- Free tier available for testing environments (with limitations)
- Useful for UAT (user acceptance testing) before deploying to production
Production (Small Agency):
- Standard 1X dyno: ~£20/month per web server
- Standard 1X background worker: ~£20/month for jobs like email sending
- Standard PostgreSQL: ~£40/month (10GB storage, 120 connections)
- Total: ~£80/month for a reliable, scalable foundation
For a letting agency managing 50–500 properties, this is considerably cheaper than:
- Hiring a DevOps engineer (£40k–60k/year)
- Managing dedicated servers (£100–300/month plus sysadmin time)
- Purchasing and maintaining on-premise infrastructure
As the agency grows, Heroku scales incrementally. Need more database storage? Upgrade the plan. Need more web servers to handle traffic? Add dynos. Unlike traditional hosting, there's no need to provision an entire new server when you outgrow the current one.
Reliability and Uptime
Heroku's SLA (Service Level Agreement) guarantees 99.95% uptime for Production-tier dynos, which translates to roughly 4 hours of permitted downtime per year. In practice, most applications experience far less downtime than this.
The platform runs on AWS infrastructure across multiple availability zones. If a physical server fails, Heroku automatically restarts the application on healthy hardware. For the application, this is invisible—requests continue being served without human intervention.
We experienced this firsthand during Week 35 when we inadvertently broke the Procfile configuration. Heroku's deployment safeguards caught the issue, rolled back automatically, and sent an alert. The application never went down. We fixed the configuration in development, pushed again, and deployment succeeded. This kind of deployment safety net is invaluable during rapid iteration.
What About Self-Hosting or AWS Directly?
Valid question. Self-hosting on AWS EC2, DigitalOcean droplets, or on-premise servers gives you complete control and potentially lower costs at scale. But it shifts responsibility:
- Security patches: You're responsible for OS updates, Ruby security patches, and PostgreSQL upgrades
- Database backups: You must configure, test, and monitor automated backups
- SSL certificates: You handle provisioning, renewal, and installation
- Monitoring: You set up logging, alerting, and performance dashboards
- Scaling: You configure load balancers and auto-scaling policies
For agencies with in-house technical teams, this is entirely feasible. For most letting agencies, it's an expensive distraction from core business activities.
Using AWS directly (via Elastic Beanstalk or ECS) sits somewhere between Heroku and self-hosting. You get more control than Heroku but more complexity than traditional hosting. We might evaluate AWS if costs exceed £500/month, but below that threshold, Heroku's convenience is worth the premium.
Multi-Region Deployments
While not implemented in Week 24, Heroku supports multi-region deployments where the application runs simultaneously in different geographical locations (e.g., EU and US). This reduces latency for international users and provides redundancy if an entire AWS region fails.
For UK-focused letting agencies, this is typically unnecessary. But for agencies with international properties or expansion plans, it's reassuring to know the platform supports it without architectural changes.
Developer Experience Matters
One final consideration: Heroku optimises for developer productivity. The deployment workflow is simple enough that junior developers can push changes confidently. The logging is comprehensive (every request, every error, every database query is logged and searchable). The dashboard provides visibility into performance metrics without requiring third-party monitoring tools.
This matters because features ship faster when developers spend less time fighting infrastructure. During Week 35, we deployed multiple times per day—sometimes a dozen or more as we iterated on photo management features. With traditional hosting, that level of iteration would require significant automation engineering. With Heroku, it just works.
When to Reconsider Heroku
No platform is perfect for every scenario. You might outgrow Heroku if:
- Monthly costs exceed £1,000: At this point, self-hosting on AWS becomes economically attractive
- You need bare-metal performance: Heroku's abstraction layers add slight overhead (typically 5–10%)
- You require exotic configurations: Heroku's standardised environment doesn't support every edge case
For the vast majority of letting agencies, these thresholds are years away—if they ever arrive at all.
What's Next
With reliable deployment in place, we could iterate rapidly on features. By the end of Week 24 (15 June), we'd added AWS S3 integration for property photos and built the foundational Property model. Each of these features deployed smoothly to production, immediately available to test in real-world conditions.
The infrastructure decisions made this week—Heroku for hosting, PostgreSQL for data, Rails 8 for the application framework—would support every feature we'd build over the following months. That's the hallmark of good foundational work: it becomes invisible, just quietly enabling everything else.
Related articles: