DEV Community: Zach Benson

Staxless: Your Scalable SaaS Starter Kit for Rapid Development and Deployment

Zach Benson — Tue, 08 Jul 2025 08:34:39 +0000

How Staxless Was Built

Staxless was born from my journey as a SaaS founder (@zach_benson817). After a year of battling complex microservice setups, I wanted freedom, flexibility, and ownership—a codebase that lets solo founders build fast without drowning in infrastructure. Think of Staxless as a LEGO set for SaaS scaling: each piece (microservice) fits perfectly, but you can swap or customize them as your app grows. Here’s how we built it:

Frontend with Next.js: Micro frontend components fetch products and auth providers, styled rapidly with Tailwind CSS for consistent branding.
Authentication: Passwordless OAuth 2.0 and magic links, configured quickly and securely.
Event-Driven Architecture with Kafka: Kafka enables asynchronous communication between services, ensuring loose coupling and scalability.
Payments with Stripe: A Stripe microservice manages checkout and webhooks, syncing subscriptions to MongoDB via Kafka events.
Content with Payload CMS: Payload CMS delivers docs, legal pages, and blogs through a user-friendly admin UI and GraphQL API.
Emails with Mailgun: Pre-configured templates simplify sending magic links and purchase confirmations.
Dockerized Deployment: Docker Compose and Docker Swarm streamline local and production setups for seamless deployment.

Staxless focused on simplicity—no over-engineered solutions, just a practical template for SaaS founders. Every component is swappable, so you’re never locked in. Want to replace MongoDB with PostgreSQL? Go for it. Prefer SendGrid over Mailgun? Easy swap. Staxless is your blank canvas, not a rigid framework.

Getting Started with Development

Ready to kick the tires on Staxless? Setting up your local development environment is straightforward, thanks to the pre-configured codebase and Docker Compose. Here’s how to get rolling in five simple steps, so you can start building your SaaS faster than you can say “monolith meltdown.”

Clone the Staxless Repo: Grab the codebase from the Staxless GitHub repo (included in your Basic or Premium plan).

   git clone https://github.com/staxless/staxless.git
   cd staxless

Install Dependencies: Ensure you have Docker, Docker Compose, and Node.js (LTS version) installed. Then, install frontend dependencies:

   cd frontend
   npm install
   cd ..

Set Up Environment Variables: Copy the template env file and add your credentials (e.g., Mailgun, Stripe, OAuth keys) from /config/secrets/dev/staxless.dev.env.template to /config/secrets/dev/staxless.dev.env. Example:

   # /config/secrets/dev/staxless.dev.env
   NODE_ENV=development
   DATABASE_URI=mongodb://mongodb-service/database
   MAILGUN_API_KEY=your-mailgun-api-key
   STRIPE_PRIVATE_KEY=your-stripe-private-key
   GOOGLE_CLIENT_ID=your-google-client-id
   GOOGLE_CLIENT_SECRET=your-google-client-secret
   GITHUB_CLIENT_ID=your-github-client-id
   GITHUB_CLIENT_SECRET=your-github-client-secret

Launch the Stack with Docker Compose: Start all services (frontend, auth, user, stripe, email, cms, Kafka, MongoDB) in development mode:

   npm run staxless-dev-build

This spins up the services, exposes ports (e.g., 3000 for frontend, 8000 for gateway, 8080 for auth), and creates Kafka topics like project-events (see /config/docker-compose.dev.yml).

Test the Setup: Verify the services are running by checking health endpoints via Kong:

   curl http://localhost:8000/auth/health
   curl http://localhost:8000/users/health
   curl http://localhost:8000/email/health

Open http://localhost:3000 in your browser to see the Next.js frontend in action.

Now you’re ready to customize Staxless for your SaaS! Edit /frontend/src/lib/brand-config.ts for branding or add new microservices (like the Project Sharing feature below). Check /config/test.sh for end-to-end tests to ensure everything’s humming. Got stuck? The Premium plan’s community forum has your back.

ConnectSphere: A Hypothetical SaaS Demo

Let’s bring Staxless to life with ConnectSphere, a community platform for indie makers to collaborate and share projects. ConnectSphere’s tagline—“Build Together, Thrive Together”—captures its mission to foster creative connections. With Staxless, we’ll set up ConnectSphere’s branding, authentication, Stripe, Mailgun, and a custom Project Sharing feature, leveraging Kafka for seamless backend communication. Here’s how:

Branding ConnectSphere

Customizing ConnectSphere’s look and feel is a snap with Staxless’s centralized branding config in /frontend/src/lib/brand-config.ts. We define the company details, colors, and SEO settings, which cascade across the Next.js frontend (e.g., header.tsx, footer.tsx). Here’s the simplified configuration:

// /frontend/src/lib/brand-config.ts
export const BRAND_CONFIG = {
  company: {
    name: 'ConnectSphere',
    tagline: 'Build Together, Thrive Together',
    description: 'A community platform for indie makers to collaborate and share projects.',
    website: 'https://connectsphere.app',
    email: 'hello@connectsphere.app',
    phone: '+1 (555) 987-6543',
    address: '456 Stellar Ave, Galaxy City, State 67890',
  },
  style: {
    colors: {
      primary: '#4A90E2', // Vibrant blue for CTAs
      primaryHover: '#357ABD', // Darker blue for hover
      background: '#F7FAFC', // Light blue-gray background
      textPrimary: '#1A202C', // Near-black for main text
      accent: '#A855F7', // Warm purple for highlights
    },
  },
  seo: {
    title: 'ConnectSphere - Collaborate & Share Projects',
    description: 'Join indie makers to build, share, and thrive together.',
    keywords: ['indie makers', 'community', 'collaboration'],
    ogImage: '/connectsphere-og.png',
  },
};

We drop connectsphere-logo.png into /frontend/public/ and apply styles in /frontend/src/app/globals.css using Tailwind classes (e.g., bg-[#F7FAFC] for the background). The result? A branded dashboard with vibrant blue CTAs, a sleek logo, and consistent styling across pages like the homepage, pricing, and features.

Authentication Setup

ConnectSphere needs secure, scalable auth. Staxless’s LUCIA auth module delivers passwordless OAuth2.0 Magic Links with Google and GitHub providers. We deploy the auth microservice using Docker Compose and configure OAuth in /microservices/auth-service/src/config/oauth-config.ts. Here’s the setup:

Spin Up the Auth Service:

   docker-compose -f config/docker-compose.dev.yml up -d auth-service

This starts the auth service on port 8080, connected to Kafka and MongoDB.

Configure OAuth Providers:

   // /microservices/auth-service/src/config/oauth-config.ts
   import { google, github } from 'lucia-auth/oauth';
   export const googleAuth = google({
     clientId: process.env.GOOGLE_CLIENT_ID,
     clientSecret: process.env.GOOGLE_CLIENT_SECRET,
     redirectUri: "http://localhost:8000/auth/google/callback",
   });
   export const githubAuth = github({
     clientId: process.env.GITHUB_CLIENT_ID,
     clientSecret: process.env.GITHUB_CLIENT_SECRET,
     redirectUri: "http://localhost:8000/auth/github/callback",
   });

Test Magic Link Flow: A user clicks “Sign In” on /frontend/src/app/(auth)/login/page.tsx, triggering a magic link email via the email service (/microservices/email-service/src/consumers/handlers/handle-send-magic-link.ts). The Kafka consumer processes the email-events topic, sending the email through Mailgun.

The login page (styled with Tailwind) looks clean and branded, thanks to the config in /frontend/src/lib/brand-config.ts. Scalability? Handled. LUCIA’s session management and Kafka’s event-driven flow ensure ConnectSphere’s micro frontend component, pulling available providers from the backend, can handle thousands of users without breaking a sweat.

Stripe Setup

To enable payments for ConnectSphere (e.g., premium memberships), we configure the Stripe microservice to handle products, subscriptions, and checkout. Here’s how to set it up:

Get a Testing API Key:
- Sign up or log into your Stripe account at stripe.com.
- Navigate to Developers > API Keys in the Stripe Dashboard.
- Copy the Test Secret Key (starts with sk_test_) and add it to /config/secrets/dev/staxless.dev.env:
```
 STRIPE_PRIVATE_KEY=sk_test_your-test-secret-key
```
Create a Product or Subscription:
- In the Stripe Dashboard, go to Products and click Add Product.
- Create a product (e.g., “ConnectSphere Premium”) with a recurring price (e.g., $10/month) or a one-time payment.
- Copy the Price ID (starts with price_) for use in the frontend or backend configuration.
- Update /microservices/stripe-service/src/config/stripe-config.ts with the Price ID if needed:
```
 export const STRIPE_CONFIG = {
   premiumPriceId: 'price_your-price-id',
 };
```
Enable the Dynamic Pricing Table:
- With the Stripe API key and product configured, the frontend (/frontend/src/app/(protected)/pricing/page.tsx) automatically fetches products from the Stripe microservice (/microservices/stripe-service/src/routes/stripe-routes.ts) and renders a dynamic pricing table styled with Tailwind CSS.
- Test the pricing page at http://localhost:3000/pricing to see the table populated with your product (e.g., ConnectSphere Premium at $10/month).
- When a user selects a plan, the Stripe microservice handles checkout via a POST /stripe/checkout endpoint, triggering a Kafka payment-events topic to sync subscription data to MongoDB.

This setup ensures ConnectSphere’s payment system is ready to handle subscriptions or one-time purchases, with webhooks (/microservices/stripe-service/src/routes/webhook-routes.ts) keeping user data in sync.

Mailgun Setup

To send emails like magic links and purchase confirmations for ConnectSphere, we configure the Mailgun microservice with pre-built templates. Here’s how to set it up:

Get Environment Variables:
- Sign up for a Mailgun account at mailgun.com.
- Navigate to Sending > Domains in the Mailgun Dashboard and add a domain (e.g., mg.connectsphere.app or use the sandbox domain for testing).
- Copy the API Key and Domain Name from Sending > Domain Settings.
- Add these to /config/secrets/dev/staxless.dev.env:
```
 MAILGUN_API_KEY=your-mailgun-api-key
 MAILGUN_DOMAIN=mg.connectsphere.app
```

Create Email Templates:

In the Mailgun Dashboard, go to Sending > Templates and create two templates:
- Magic Link Template: Named magic-link, with variables {{token}} and {{link}} (e.g., <a href="{{link}}">Sign In</a>).
- Purchase Confirmation Template: Named purchase-confirmation-template, with variables {{orderId}} and {{items}} (e.g., “Thank you for your purchase! Order: {{orderId}}”).
These templates are pre-configured in /microservices/email-service/src/config/templateConfig.ts:

 export const templateConfig: TemplateConfigMap = {
   'magic-link': {
     templateName: 'magic-link',
     requiredVariables: ['token', 'link'],
     subject: 'Your Magic Link',
   },
   'purchase-confirmation': {
     templateName: 'purchase-confirmation-template',
     requiredVariables: ['orderId', 'items'],
     subject: 'Purchase Confirmation',
   },
   'welcome': {
     templateName: 'welcome-template',
     requiredVariables: ['name'],
     subject: 'Welcome to Our App!',
   },
 };

Add Custom Templates (Optional):

To add more email templates (e.g., for project notifications), create a new template in Mailgun with required variables (e.g., {{projectTitle}}).
Update /microservices/email-service/src/config/templateConfig.ts with the new template:

 export const templateConfig: TemplateConfigMap = {
   ...templateConfig,
   'project-notification': {
     templateName: 'project-notification-template',
     requiredVariables: ['projectTitle', 'userName'],
     subject: 'New Project Shared!',
   },
 };

Test Email Sending:
- Trigger a magic link email by attempting a login at http://localhost:3000/login.
- The email service consumes the email-events topic via Kafka and sends the email using Mailgun.
- Check your inbox (or Mailgun’s Sending > Logs) to verify delivery.

This setup ensures ConnectSphere can send branded, reliable emails for authentication and transactions, with the flexibility to add custom templates as needed.

Adding a Custom Feature: Project Sharing with Kafka Integration

ConnectSphere’s killer feature is Project Sharing, letting users post and upvote projects (think Product Hunt for indie makers). We create a new microservice using Staxless’s Premium tier code snippets, integrating it with the existing architecture and leveraging Kafka for asynchronous communication between the project service and user service (e.g., to track user activity or notify followers). Here’s how:

Create the Project Service: We scaffold a new Node Express microservice in /microservices/project-service/, modeled after user-service. The Dockerfile (/config/dockerfiles/project-service.Dockerfile) mirrors user-service.Dockerfile:

   FROM node:lts AS builder
   USER node
   WORKDIR /home/node
   COPY --chown=node:node ["../package.json", "./"]
   RUN ["npm", "install"]
   COPY --chown=node:node ["../", "."]
   FROM builder AS dev
   RUN ["npm", "install", "nodemon", "--save-dev"]
   EXPOSE 8086
   CMD ["npm", "run", "dev"]
   FROM node:alpine AS prod
   USER node
   WORKDIR /home/node
   COPY --chown=node:node --from=builder /home/node/ ./
   CMD ["npm", "run", "prod"]

Define the Project Model: In /microservices/project-service/src/models/project-model.ts, we define a MongoDB schema:

   import { MongoClient, ObjectId } from 'mongodb';
   import { connectDB } from '../config/db-config';
   interface ProjectType {
     _id: ObjectId;
     title: string;
     description: string;
     userId: string;
     upvotes: number;
     created_at: Date;
   }
   const projectSchema = {
     bsonType: 'object',
     required: ['title', 'description', 'userId', 'upvotes', 'created_at'],
     properties: {
       _id: { bsonType: 'objectId' },
       title: { bsonType: 'string' },
       description: { bsonType: 'string' },
       userId: { bsonType: 'string' },
       upvotes: { bsonType: 'int' },
       created_at: { bsonType: 'date' },
     },
   };
   let db: MongoClient['db'];
   const initializeDatabase = async () => {
     const connection = await connectDB();
     db = connection.db(process.env.DATABASE_NAME);
     const collections = await db.listCollections({ name: 'projects' }).toArray();
     if (collections.length === 0) {
       await db.createCollection('projects', { validator: { $jsonSchema: projectSchema } });
     }
   };
   initializeDatabase().catch(() => {});
   export const Project = {
     async create(projectData: Omit<ProjectType, '_id'>) {
       projectData.created_at = new Date();
       projectData.upvotes = 0;
       const result = await db.collection('projects').insertOne(projectData);
       return result;
     },
     async upvote(projectId: string, userId: string) {
       const result = await db.collection('projects').updateOne(
         { _id: new ObjectId(projectId), userId: { $ne: userId } },
         { $inc: { upvotes: 1 } }
       );
       return result;
     },
   };

Set Up Kafka Producer for Project Events: In /microservices/project-service/src/config/kafka-client.ts, we configure a Kafka producer (similar to /microservices/stripe-service/src/config/kafka-client.ts):

   import { Kafka, Producer } from 'kafkajs';
   const kafka = new Kafka({
     clientId: 'staxless-app',
     brokers: ['kafka:29092'],
   });
   export const createProducer = (): Producer => {
     return kafka.producer();
   };

Add Project Routes with Kafka Publishing: In /microservices/project-service/src/routes/project-routes.ts, we define endpoints that publish events to Kafka’s project-events topic:

   import express from 'express';
   import { Project } from '../models/project-model';
   import { createProducer } from '../config/kafka-client';
   import logger from '../lib/logger';
   const router = express.Router();
   const producer = createProducer();
   router.post('/projects', async (req, res) => {
     try {
       const project = await Project.create(req.body);
       await producer.connect();
       await producer.send({
         topic: 'project-events',
         messages: [
           {
             key: 'project.created',
             value: JSON.stringify({
               projectId: project.insertedId,
               userId: req.body.userId,
               title: req.body.title,
               timestamp: new Date().toISOString(),
             }),
           },
         ],
       });
       await producer.disconnect();
       res.json(project);
     } catch (_error) {
       logger.error('Failed to create project or publish event', _error);
       res.status(500).json({ error: 'Failed to create project' });
     }
   });
   router.post('/projects/:id/upvote', async (req, res) => {
     try {
       const { id } = req.params;
       const userInfo = JSON.parse(req.headers['x-user-info'] as string);
       const result = await Project.upvote(id, userInfo.user_id);
       await producer.connect();
       await producer.send({
         topic: 'project-events',
         messages: [
           {
             key: 'project.upvoted',
             value: JSON.stringify({
               projectId: id,
               userId: userInfo.user_id,
               timestamp: new Date().toISOString(),
             }),
           },
         ],
       });
       await producer.disconnect();
       res.json(result);
     } catch (_error) {
       logger.error('Failed to upvote project or publish event', _error);
       res.status(500).json({ error: 'Failed to upvote project' });
     }
   });
   export default router;

Set Up Kafka Consumer in User Service: To track user activity (e.g., project posts or upvotes), we add a Kafka consumer to the user service in /microservices/user-service/src/consumers/handlers/handle-project-activity.ts:

   import type { KafkaMessage } from 'kafkajs';
   import { User } from '../../models/user-model';
   import logger from '../../lib/logger';
   export default async function handleProjectActivity(message: KafkaMessage) {
     try {
       const { projectId, userId, title, timestamp } = JSON.parse(message.value?.toString());
       const user = await User.findOne({ _id: userId });
       if (user) {
         await User.updateSubscription(userId, {
           ...user.subscription,
           lastActivity: timestamp,
         });
         logger.info(`Updated user ${userId} activity for project ${projectId}`);
       }
     } catch (_error) {
       logger.error('Error processing project activity event', _error);
     }
   }

Register the Consumer: In /microservices/user-service/src/consumers/handlers/index.ts, we update the event registry:

   import type { KafkaMessage } from 'kafkajs';
   import handleSubscriptionUpdate from './handle-subscription-update';
   import handleProjectActivity from './handle-project-activity';
   export const paymentEventRegistry = new Map<
     string,
     (message: KafkaMessage) => Promise<void>
   >([
     ['user.subscription.updated', handleSubscriptionUpdate],
     ['project.created', handleProjectActivity],
     ['project.upvoted', handleProjectActivity],
   ]);

Update Docker Compose: We update /config/docker-compose.dev.yml to include the project service and Kafka topic setup:

   services:
     project-service:
       image: app_project_service
       build:
         context: ../microservices/project-service/
         dockerfile: ../../config/dockerfiles/project-service.Dockerfile
         target: dev
       env_file:
         - ../config/secrets/dev/staxless.dev.env
       ports:
         - "8086:8086"
       expose:
         - "8086"
       volumes:
         - ../microservices/project-service/src:/home/node/src
       environment:
         - NODE_ENV=development
       networks:
         backend:
           aliases:
             - "project"
     kafka-setup:
       image: confluentinc/cp-kafka:7.5.0
       depends_on:
         - kafka-service
       networks:
         - backend
       command: >
         bash -c "
           echo 'Waiting for Kafka to be ready...' &&
           cub kafka-ready -b kafka:29092 1 20 &&
           echo 'Kafka is ready!' &&
           kafka-topics --create --topic auth-events --bootstrap-server kafka:29092 --partitions 1 --replication-factor 1 &&
           kafka-topics --create --topic email-events --bootstrap-server kafka:29092 --partitions 1 --replication-factor 1 &&
           kafka-topics --create --topic payment-events --bootstrap-server kafka:29092 --partitions 1 --replication-factor 1 &&
           kafka-topics --create --topic user-events --bootstrap-server kafka:29092 --partitions 1 --replication-factor 1 &&
           kafka-topics --create --topic project-events --bootstrap-server kafka:29092 --partitions 1 --replication-factor 1 &&
           kafka-topics --create --topic session-validation-replies --bootstrap-server kafka:29092 --partitions 1 --replication-factor 1 &&
           echo 'Topics created successfully.'
         "

Test the API via Kong: With Kong running, we test the project creation endpoint, which triggers a Kafka event:

   curl -X POST http://localhost:8000/projects -H "Content-Type: application/json" -H "x-user-info: {\"user_id\": \"60d5f1b4e6b3f1b3f8f1b3f8\"}" -d '{"title": "My Indie Project", "description": "A cool app for makers", "userId": "60d5f1b4e6b3f1b3f8f1b3f8"}'

Verify Kafka Event: We check the project-events topic to confirm the event was published:

   docker exec staxless-kafka-1 kafka-console-consumer --bootstrap-server localhost:29092 --topic project-events --from-beginning --timeout-ms 5000

Output:

   {"projectId":"507f1f77bcf86cd799439011","userId":"60d5f1b4e6b3f1b3f8f1b3f8","title":"My Indie Project","timestamp":"2025-07-08T06:06:00.000Z"}

The Project Sharing feature leverages Kafka to decouple the project service (handling posts and upvotes) from the user service (tracking activity). When a user posts a project, the project service publishes a project.created event to the project-events topic. The user service consumes this event, updating the user’s lastActivity field in MongoDB. This async communication ensures ConnectSphere scales effortlessly, even with thousands of projects and users. The frontend (/frontend/src/app/(protected)/dashboard/page.tsx) displays projects in a Tailwind-styled grid, branded with ConnectSphere’s blue palette.

[Frontend] --> [Kong Gateway] --> [Project Service]
                                      |
                                      v
                               [Kafka: project-events]
                                      |
                                      v
                               [User Service] --> [MongoDB]

Outcome

With Staxless, ConnectSphere went from concept to a scalable, branded SaaS in days, not months. The Kafka-driven Project Sharing feature ensures loose coupling and scalability, while Stripe and Mailgun setups enable seamless payments and email communication. The modular architecture lets you swap components (e.g., add Firebase for real-time notifications) without refactoring. Founders can focus on community-building—engaging makers, iterating features, and sharing their #BuildInPublic journey—while Staxless handles the heavy lifting.

Deploying via Digital Ocean

Ready to take ConnectSphere live? Staxless’s Dockerized setup makes deployment on Digital Ocean a breeze, whether you use a Droplet (virtual machine) or App Platform (PaaS). Here’s how to deploy your Staxless stack, ensuring your SaaS is accessible to the world with minimal fuss.

Option 1: Deploy on a Digital Ocean Droplet

Create a Droplet:
- Log into Digital Ocean and create a Droplet (e.g., Ubuntu 22.04, 4GB RAM, 2 vCPUs for small apps).
- Enable SSH access and add your public key for secure access.
Install Docker and Docker Compose:
SSH into your Droplet and install Docker:

   sudo apt update
   sudo apt install -y docker.io docker-compose
   sudo systemctl start docker
   sudo systemctl enable docker

Clone and Configure Staxless: Clone the Staxless repo and copy your production environment variables to /config/secrets/prod/ (e.g., auth-service.env, stripe-service.env from /config/secrets/prod/*.env.template):

   git clone https://github.com/staxless/staxless.git
   cd staxless
   cp config/secrets/dev/staxless.dev.env config/secrets/prod/staxless.prod.env

Edit staxless.prod.env with your production credentials (e.g., MongoDB Atlas URI, Mailgun API key, Stripe secret key). Example:

   # /config/secrets/prod/staxless.prod.env
   NODE_ENV=production
   DATABASE_URI=mongodb+srv://user:pass@cluster0.mongodb.net/database
   MAILGUN_API_KEY=your-mailgun-api-key
   STRIPE_PRIVATE_KEY=your-stripe-private-key

Update Docker Compose for Production: Modify /config/docker-compose.prod.yml to expose only necessary ports (e.g., 8000 for Kong) and set NODE_ENV=production. Example change:

   services:
     frontend:
       ports:
         - "80:3000" # Map port 80 to frontend

Deploy the Stack: Start the production stack:

   docker-compose -f config/docker-compose.prod.yml up -d

This builds and runs all services (frontend, auth, user, stripe, email, cms, Kafka, MongoDB) with production settings.

Set Up a Domain and SSL:
- Point your domain (e.g., connectsphere.app) to the Droplet’s IP via Digital Ocean’s DNS.
- Install an SSL certificate using Let’s Encrypt:
```
 sudo apt install -y certbot python3-certbot-nginx
 sudo certbot --nginx -d connectsphere.app
```
Test the Deployment:
Verify services are live:

   curl https://connectsphere.app/auth/health

Visit https://connectsphere.app to see your SaaS in action.

Option 2: Deploy on Digital Ocean App Platform

Set Up App Platform:
- In Digital Ocean, create a new App and select your Staxless repo from GitHub.
- Choose the Docker app type and specify config/docker-compose.prod.yml as the compose file.
Configure Environment Variables:
Add your production env variables in the App Platform UI, matching /config/secrets/prod/staxless.prod.env.
Deploy the App:
- Deploy the app, selecting a region (e.g., New York) and a plan (e.g., Basic for small apps).
- App Platform automatically builds and deploys your services, handling scaling and load balancing.
Add a Domain and SSL:
- Link your domain in the App Platform settings.
- Enable automatic SSL via Digital Ocean’s built-in Let’s Encrypt integration.
Monitor and Scale:
Use App Platform’s dashboard to monitor performance and scale resources as your user base grows.

Post-Deployment

Run Tests: Use /config/test.sh to verify end-to-end functionality (e.g., magic link flow, Stripe webhooks) in production.
Set Up Monitoring: Add Digital Ocean’s monitoring tools or integrate a third-party service like New Relic.
Join the Community: Premium plan users can access the Staxless Discord forum for deployment tips and support.

Your SaaS is now live on Digital Ocean, ready to scale with your community. Need help? DM me @zach_benson817 on X!

Get Started with Staxless

Ready to scale your SaaS like ConnectSphere? Staxless’s Basic plan ($299) gets you the full codebase, while the Premium plan ($499 or 3x $170) adds access to our Discord community forum and exclusive code snippets. Join the #BuildInPublic crew, save weeks of dev time, and build a SaaS that grows with you.

Got feedback? DM me @zach_benson817 on X!

Join the Staxless Waitlist Now

Quantum Convolutional Neural Networks

Zach Benson — Tue, 28 May 2024 03:50:04 +0000

This blog post is about utilizing AWS ML services to build Quantum Convolutional Neural Networks (QCNN). To do so, we utilize Amazon SageMaker, PennyLane, and PyTorch to train and test QCNNs on simulated quantum devices. Previously, it has been demonstrated that QCNNs can be used for binary classification tasks. This blog post will go one step further and show how to construct a QCNN for multi-class classification and apply it to image classification tasks. Based on the steps shown in this post, you can begin to explore the use cases of QCNNs by building, training, and evaluating your own model.

Approach

To implement this solution, we used PennyLane, PyTorch, SageMaker notebooks, and the public MNIST and Fashion-MNIST datasets. The specific notebook instances were ml.m5.2xlarge - ml.m5.24xlarge.

PennyLane

PennyLane is a Python library for programming quantum computers. Its differentiable programming paradigm enables the execution and optimization of quantum programs on a variety of simulated and hardware quantum devices. It manages the execution of quantum computations, including the evaluation of circuits and their gradients. This information can then be forwarded to the classical framework, creating seamless quantum-classical pipelines for applications, including the building of Quantum Neural Networks. Additionally, PennyLane offers integration with ML frameworks such as PyTorch.

PyTorch

PyTorch is an open-source, deep learning framework that makes it easy to develop ML models and deploy them to production. PyTorch has been integrated into the PennyLane ecosystem, allowing for the creation of hybrid Quantum-Classical ML models. Furthermore, this integration has allowed for the native training of QML models in SageMaker.

Amazon SageMaker

SageMaker is a fully managed service that provides every developer and data scientist with the ability to build, train, and deploy ML models quickly. SageMaker removes the heavy lifting from each step of the ML process to make it easier to develop high-quality models. With its integration of PyTorch, practitioners are able to build, train, and deploy their own PyTorch models on SageMaker.

Overview of Quantum Computing

Quantum Bits

Quantum computing isn’t built on bits that aren’t binary in nature. Rather, quantum bits (qubits) are two-state quantum mechanical systems that can be a combination of both zero and one at the same time. In addition to this property of “superposition”, qubits can be “entangled”, allowing for N qubits to act as a group rather than in isolation. As a result, qubits can achieve exponentially higher information density (2^N) than the information density of a classical computer (N).

Quantum Circuits

Quantum circuits are the underlying framework for quantum computation. Each circuit is built sequentially and consists of three stages: preparation of a fixed initial state, gate transformations, and measurement of an observable(s).

Preparation: In the first stage, the qubits are initialized with the quantum or classical data that is going to be used for computation. Several options exist for encoding classical data onto qubits. For our experiment, we elected to use Amplitude embedding, which takes 2^qubits data points as the initial state.
Transformations: In the second stage, gate-based transforms are applied to the qubits. This stage can be as simple as a one-gate operation or as complex as a grouping of gates. When several gates are grouped, they are often referred to as a unitary.
Measurement: Lastly, the circuit is completed with the measurement of an observable. This observable may be made up of local observables for each wire in the circuit or just a subset of wires. Prior to this stage, the qubits have been in superposition, representing a mixture of the states 0 and 1. However, when a qubit is measured, this state collapses into either 0 or 1, with an associated probability of doing so.

Quantum Optimization

Variational or parameterized quantum circuits are quantum algorithms that depend on free parameters. Much like standard quantum circuits, they consist of the preparation of the fixed input state, a set of unitaries parameterized by a set of free parameters θ, and measurement of an observable ^B at the output. The output or expectation value, with some classical post-processing, can represent the cost of a given task. Given this cost, the free parameters θ=(θ1,θ2,...) of the circuit can be tuned and optimized. This optimization can leverage a classical optimization algorithm such as stochastic gradient descent or Adam.

Quantum Convolutional Neural Network

Quantum convolutions are a unitary that act on neighboring pairs of qubits. When this unitary is applied to every neighboring pair of qubits, a convolution layer is formed. This convolution layer mirrors the kernel-based convolutional layer found in the classical case. Below is the structure of the convolutional unitary that was used for this project.

These convolutions are followed by pooling layers, which are effected by measuring a subset of the qubits and using the measurement results to control subsequent operations. Shown below is the structure that was used:

The analogue of a fully-connected layer is a multi-qubit operation on the remaining qubits before the final measurement. This essentially maps the information from the remaining qubits to the ancillary qubits for our final measurement. The structure for doing so is the following:

The resulting network architecture is two convolution layers, two pooling layers, and the ancillary mapping.

Building the Model

PennyLane Basics

To begin constructing a quantum circuit, we must first define the quantum simulator or hardware device that will be used.
```
import pennylane as qml
dev = qml.device('default.qubit', wires=1)
# Specify how many qubits are needed
```

Now that the device is defined, we can begin building our quantum circuit.

@qml.qnode(dev)
def circuit(input):
    qml.RX(input, wires=0)  # Quantum Gate
    return qml.sample(qml.PauliZ(wires=0))  # Measurement of the PauliZ

To visualize the circuit, we can call draw_mpl(), with the required inputs of the circuit.

from matplotlib import pyplot as plt
input = 1
fig, ax = qml.draw_mpl(circuit)(input)
plt.show()

Advanced PennyLane

Establish the quantum device that will be used for our circuit.

import pennylane as qml

num_wires = 12
num_ancilla = 4
device_type = 'lightning.qubit'
dev = qml.device(device_type, wires=num_wires)

Define the quantum model.

def circuit(num_wires, num_ancilla):
    @qml.qnode(dev, interface='torch', diff_method='adjoint')
    def func(inputs, params):
        work_wires = list(range(num_wires - num_ancilla))
        ancilla_wires = list(range(len(work_wires), num_wires))
        qml.AmplitudeEmbedding(inputs, wires=work_wires, normalize=True)

        work_wires, params = Conv1DLayer(unitarity_conv1d, 15)(work_wires, params)
        work_wires, params = PoolingLayer(unitarity_pool, 2)(work_wires, params)
        work_wires, params = Conv1DLayer(unitarity_conv1d, 15)(work_wires, params)
        work_wires, params = PoolingLayer(unitarity_pool, 2)(work_wires, params)

        unitarity_toffoli(work_wires, ancilla_wires)

        return [qml.expval(qml.PauliZ(wire)) for wire in ancilla_wires]
    return func

Wrap our quantum circuit into a PyTorch Model.

params_shapes = {"params": 357}
qlayer = qml.qnn.TorchLayer(circuit(num_wires, num_ancilla), params_shapes, torch.nn.init.normal_)
output = torch.nn.Softmax(dim=1)

Initialize the model with the layers that we just made.
```
model = torch.nn.Sequential(qlayer, output)
```

Training the Quantum Model

For training, we conducted an experiment on a subset of the MNIST and Fashion-MNIST datasets.

# Hyperparameters
epochs = 8
batch_size = 32
train_samples = len(train_data)
batches = train_samples // batch_size

from tqdm.notebook import trange
opt = torch.optim.Adam(model.parameters(), lr=0.001)

for epoch in range(epochs):
    running_loss = 0
    batch = 0
    model.train()
    for batch, i in zip(train_loader, trange(batches)):
        data = batch[0]
        target = batch[1]
        opt.zero_grad()
        pred = model(data)
        loss_evaluated = loss(pred, target)
        loss_evaluated.backward()
        opt.step()
        running_loss += loss_evaluated
        print(running_loss.item() / (i + 1), end='\r')
    avg_loss = running_loss / batches
    res = [epoch + 1, avg_loss]
    print("Epoch: {:2d} | Loss: {:3f} ".format(*res))

Evaluating the Model

correct = 0
total = 0
with torch.no_grad():
    model.eval()
    for batch in test_loader:
        data = batch[0]
        target = batch[1]
        predicted = model(data)
        predicted = torch.argmax(predicted, 1)
        total += target.size(0)
        correct += (predicted == target).sum().item()
print('Accuracy of the network on {:2d} test images: {:.3f} %'.format(total, (100 * correct / total)))

Saving and Loading the Model

torch.save(model.state_dict(), PATH)
python
Copy code
model = torch.nn.Sequential(qlayer, output)
model.load_state_dict(torch.load(PATH))
model.eval()

Deploying Model to SageMaker Endpoint

To deploy this model to a SageMaker endpoint, one would follow the standard steps for deploying a PyTorch model on SageMaker. The only additional step needed would be to extend the existing PyTorch container instance to include PennyLane.

Results

For the subset of the MNIST dataset, the average accuracy after 8 epochs was 92%. For the Fashion-MNIST dataset, the average accuracy after 8 epochs was 88%.

Next Steps

There are various methods that can be used to encode data onto the quantum circuit. To be able to further leverage the information density of qubits, these methods should be further explored. This could allow for larger and more complex datasets to be used for training.
Exploring further, the specific convolutional unitary used in this blog is one of many that could be used. It is possible that there are more efficient methods for conducting the convolution.
Lastly, due to the quantum circuits being supported in PyTorch, it is possible to explore Quantum-Classical model architectures for multi-class classification. This enables support of transfer learning from well-established pre-built models.

Conclusion

In this post, we demonstrated how quantum computing can be leveraged for multi-class image classification tasks. Moreover, we showed you how this can be accomplished on available Amazon SageMaker instances, using PennyLane for building QCNNs and PyTorch to facilitate model training and deployment. Furthermore, we discussed mechanisms that enabled the construction of QCNNs, and their training.

If you would like to look deeper at the code:

zacharybenson / quantum-cnn

Quantum Deep Learning

Example Jupyter notebooks that demonstrate how to build, train, and deploy machine learning models using Amazon SageMaker.

📚 Background

Amazon SageMaker is a fully managed service for data science and machine learning (ML) workflows You can use Amazon SageMaker to simplify the process of building, training, and deploying ML models.

The SageMaker example notebooks are Jupyter notebooks that demonstrate the usage of Amazon SageMaker.

Quantum machine learning (QML) has emerged as the potential solution to address the challenge of handling an ever-increasing amount of data. With these advancements there is potential for reduced training times, and hybrid quantum-classical architectures.

🛠️ Setup

The quickest setup to run example notebooks includes:

📓 Examples

Introduction to Seqeuntial Circuits

These examples provide quick walkthroughs to get you up and running with the labeling job…

View on GitHub

Could Micro Services Be a Good Fit for Micro SaaS?

Zach Benson — Fri, 24 May 2024 22:31:59 +0000

Could Microservices Be a Good Fit for Micro SaaS Startups?

As a solo developer, I've been intrigued by the potential of microservices for small SaaS and micro SaaS projects. Balancing the constraints of limited resources with the option to scale quickly, I've been contemplating whether microservices could be a good fit for smaller projects. The consensus? It's a bit obvious - it promising, if you can overcome the inherent challenges of microservices without expending substantial development time. With that being said I would like to share what I have found while developing my own micro service boilerplate and hopefully help you get there faster.

The Appeal of Microservices for Micro SaaS Startups

Microservices architecture breaks down applications into small, independent deployable services, each responsible for a specific piece of functionality. This modular approach offers several compelling advantages for micro SaaS developers:

Scalability: Startups can scale individual services based on demand without scaling the entire application. This efficient resource use is crucial when budgets are tight.
Flexibility and Agility: Each microservice can be developed, deployed, and scaled independently, allowing startups to iterate quickly and adapt to market changes with minimal disruption.
Fault Isolation: Issues in one service do not necessarily affect the entire application, leading to more resilient systems and better uptime.
Technology Diversity: Teams can choose the best technology stack for each service, enabling experimentation with new technologies that could give a competitive edge.
- My interest in microservices is specifically the flexibility and technology diversity.

Overcoming the Overhead of Microservices

Despite the benefits, microservices come with their own set of challenges, particularly for startups with limited resources and experience in managing distributed systems. However, these challenges can be mitigated with the right strategies and tools.

Challenge 1: Complexity of Distributed Systems

Solution: Leverage Automation and Orchestration Tools

Automated Deployment: Use tools like Docker for containerization and Kubernetes for orchestration to manage deployment and scaling. These tools simplify the process of managing multiple services, making the system more robust and easier to handle.
- Containerization with Docker can be slow to start if you are learning, but once you have it down containerizing each micro-service will come pretty quickly.
- Orchestration with Kubernetes is simple to set up, but there are some challenges to managing resource usage in a cost effective way.

Challenge 2: Ensuring Effective Communication

Solution: Standardize Communication Protocols

API Gateways: Use an API gateway to manage and route requests between clients and services, providing a single entry point for the system. This simplifies client-side logic and improves security.
Event-Driven Architecture: Implement asynchronous communication using message brokers (e.g., RabbitMQ, Kafka) to decouple services and improve system resilience.
- My pick is using an API gateway, as it has the added benefit of protecting all of your backend api's behind one end point where you can implement authentication/authorization, rate limiting, and reverse proxies.

Challenge 3: Managing Data Consistency

Solution: Embrace Eventual Consistency

Shared Database: Allow multiple services use the same database. It simplifies ensuring data consistency but increases coupling between services and reduces their autonomy. This is a particularly good fit for smaller solo developers or small teams because communication between service owners is a bit simpler.
Database Per Service: Adopt a database per service pattern to ensure services are loosely coupled, which allows each service to manage its own data independently.
- My pick is using a shared database that is its own service. As a solo dev it is straight forward enough to keep track of the changes services have on the database. With it being its own service the api calls are mostly what change.

Challenge 4: Finding the Right Service Boundaries

Solution: Start Simple and Iterate

Domain-Driven Design (DDD): Embrace DDD principles to carve out precise service boundaries aligned with your business functions. Kick off with a broad decomposition and refine iteratively as your understanding of the application's needs evolves.
Leverage Common Solutions: Take a moment to survey the landscape. In the realm of SaaS and micro SaaS, certain fundamental services consistently appear: authentication, user management, email handling, and payment processing. Rather than reinventing the wheel for these essentials, capitalize on existing solutions. Direct your efforts towards dissecting the distinctive features of your application.

Conclusion

Microservices offer promising benefits for micro SaaS startups, enabling scalability, flexibility, and resilience. However, they also pose challenges, especially for those with limited resources. By leveraging automation tools, standardizing communication protocols, embracing eventual consistency, and starting with simple service boundaries, startups can effectively harness the power of microservices. Through iterative refinement and strategic decision-making, microservices can indeed be a valuable asset for smaller projects.

Stay tuned as I share my journey implementing these strategies in my microservice boilerplate, Staxless.

References

Microservices Patterns: With Examples in Java - Chris Richardson

Feel free to leave your comments and suggestions below. Let's learn and grow together as a community!