Every time I push code to Jottings' repository, something magical happens. Within seconds, the changes are live. No waiting for deployment pipelines. No manual build steps. No deployment checklists. Just code → push → deployed.
This isn't luck. It's GitHub Actions.
The Push-to-Deploy Dream
When I started building Jottings, I made a conscious decision: keep infrastructure as simple as possible. A serverless architecture helped with that. But what about deployments?
I could have built an elaborate CI/CD pipeline. Pre-deployment checks. Testing gates. Approval workflows. Blue-green deployments. The works.
Instead, I chose something radical: automatic deployments on every push to main and develop branches. No gatekeeping. No waiting. Just deploy.
"That's risky," you might think. And yeah, it can be. But it's also honest. It forces discipline. It makes you think twice before pushing. And when something breaks, you fix it fast.
Why GitHub Actions
GitHub Actions isn't the most sophisticated CI/CD tool. But it's the right tool for Jottings.
Here's why:
It lives where the code lives. I don't need another SaaS account. No API keys scattered across secret managers. The workflows are version-controlled, right in the repository. I can trace exactly when a workflow changed and why.
It's serverless-friendly. My entire backend runs on AWS Lambda. GitHub Actions integrates cleanly with AWS via IAM roles and environment-based secrets. Set it once, forget it works.
It's cost-effective. Free for public repositories. For private ones, you get 2,000 minutes per month included with GitHub Pro. I've never exceeded that quota.
It's boring, which is good. It doesn't have a learning curve. Anyone on the team can understand the workflow files in seconds. That's the opposite of "clever," which is exactly what you want in infrastructure.
Our Deployment Workflow
Here's how Jottings actually ships code:
Frontend (SvelteKit): Push → GitHub → Cloudflare Pages webhook → Auto-deploy to dev-dashboard.jottings.me or production
The Cloudflare Pages integration handles everything. I configured it once, and it hasn't needed attention since. Cloudflare detects pushes to specific branches and deploys automatically. For the dashboard, it's this simple.
Backend (AWS Lambda + Express): Push to main → GitHub Actions → Run deployment script → Lambda functions updated across all endpoints
The workflow is straightforward:
- Detect push to
mainordevelop - Check out code
- Install dependencies
- Run Serverless Framework deploy command
- Update Lambda functions, API Gateway routes, DynamoDB tables
- Verify deployment succeeded
All of this happens in about 90 seconds.
Here's the real magic: the same workflow deploys to both dev and production. I don't maintain separate pipelines. One workflow. Two environments. Different secrets injected by GitHub based on the branch.
The Branch Strategy
We use a simple three-branch model:
main - Production. Stable, tested, reviewed code lives here. When I push to main, customers immediately see new features.
develop - Staging. Where feature branches merge. A proving ground. If something breaks here, I know about it before production.
Feature branches - Off develop, reviewed via pull request, merged back to develop. Nothing touches production until it's proven on develop.
This isn't original thinking. But it works. And more importantly, it's enforced by automation. I don't need to remember the branching strategy. GitHub Actions won't let me deploy from the wrong branch because the workflow only triggers on main and develop.
The Controversial Part: No Pre-Deployment Checks
Here's where I lose some people: we don't run tests in the CI pipeline.
No linting. No test suite. No type checking. Nothing.
"But what if your code is broken?" it's always asked.
Fair question. Here's my answer: tests run locally, before pushing. I run the full test suite on my machine. I lint. I check types. I do all the pre-flight checks. Then I push.
This approach works because:
I'm disciplined about it. When I'm about to push to main, I know what I'm changing. I test it.
The barrier to entry is low. If someone on the team needs to deploy, they don't need to understand the CI/CD system. They just need to make sure their code works locally.
Deployment is fast. No waiting for tests to pass. No debugging failed CI runs. The feedback loop is tight.
It aligns with Jottings' philosophy. We're building a lightweight platform. Every decision should remove friction, not add it. Elaborate test gates feel like friction.
The downside? If someone pushes broken code, it's live immediately. In practice, this rarely happens because the act of pushing is a deliberate decision. You're accountable.
Is this approach suitable for every team? No. For Jottings, with a small team and frequent deployments? Absolutely.
Secrets and Security
The only tricky part of this setup: AWS credentials.
GitHub Actions needs AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY to deploy Lambda functions. These are sensitive.
Our approach:
- Store secrets in GitHub's encrypted secret manager
- IAM user created specifically for deployments (not the admin account)
- Secrets limited to the minimum required permissions (deploy Lambda, update API Gateway, manage DynamoDB)
- Rotated every quarter
GitHub Secrets are encrypted at rest and decrypted only when the workflow runs. They're not printed in logs. They're not accessible to PR reviewers. This is good enough for our trust model.
The Result
Push code → 90 seconds → live
No meetings about deployment windows. No fear of going live. No "someone needs to babysit the deployment."
The infrastructure gets out of the way.
What's Next
As Jottings grows, this approach might change. If we hire a larger team, we'll probably add more gates. If we handle sensitive financial data differently, we'll enforce more checks.
But for now? This is the right level of automation. Enough to be productive. Not so much that it becomes a burden.
If you're building a serverless project and wondering about CI/CD, I'd recommend starting here. Keep it simple. Add complexity only when you need it.
Building something? Jottings is designed for people who want to share their thoughts without the complexity of traditional blogging platforms. Push your ideas live with the same simplicity as our deployments.