diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
deleted file mode 100644
index b6aa5b6..0000000
--- a/CONTRIBUTING.md
+++ /dev/null
@@ -1,129 +0,0 @@
-# Contributing to Passkey Auth
-
-Thank you for your interest in contributing to Passkey Auth! This document provides guidelines for contributing to the project.
-
-## 🚀 Getting Started
-
-1. Fork the repository
-2. Clone your fork: `git clone https://github.com/yourusername/passkey-auth.git`
-3. Create a feature branch: `git checkout -b feature/your-feature-name`
-4. Make your changes
-5. Test your changes
-6. Commit and push to your fork
-7. Create a Pull Request
-
-## 🛠️ Development Setup
-
-### Prerequisites
-- Go 1.21 or later
-- Docker (for containerized testing)
-- Make (optional, for build scripts)
-
-### Local Development
-```bash
-# Clone the repository
-git clone https://github.com/yourusername/passkey-auth.git
-cd passkey-auth
-
-# Install dependencies
-go mod download
-
-# Run the application
-go run .
-
-# Run tests
-go test ./...
-```
-
-### Docker Development
-```bash
-# Build Docker image
-./scripts/build.sh
-
-# Run with Docker
-docker run -p 8080:8080 passkey-auth
-```
-
-## 📋 Guidelines
-
-### Code Style
-- Follow standard Go formatting (`gofmt`)
-- Use meaningful variable and function names
-- Add comments for exported functions and complex logic
-- Keep functions focused and small
-
-### Commit Messages
-- Use clear, descriptive commit messages
-- Start with a verb in present tense ("Add", "Fix", "Update")
-- Include context for why the change was made
-
-Example:
-```
-Add email allowlist support for user registration
-
-- Allows administrators to restrict registration to specific email domains
-- Configurable via config.yaml or environment variables
-- Backwards compatible (empty list allows all emails)
-```
-
-### Testing
-- Write tests for new features
-- Ensure existing tests pass
-- Test both success and error cases
-- Include integration tests for new endpoints
-
-### Documentation
-- Update README.md for new features
-- Add inline code comments
-- Update API documentation if endpoints change
-- Include examples in documentation
-
-## 🐛 Bug Reports
-
-When reporting bugs, please include:
-- Go version
-- Operating system
-- Steps to reproduce
-- Expected vs actual behavior
-- Relevant logs or error messages
-
-## 💡 Feature Requests
-
-When requesting features:
-- Describe the use case
-- Explain why it would be valuable
-- Consider backwards compatibility
-- Provide examples if possible
-
-## 🔐 Security
-
-For security vulnerabilities:
-- Do not open public issues
-- Contact maintainers directly
-- Provide detailed reproduction steps
-- Allow time for fixes before disclosure
-
-## 📜 Code of Conduct
-
-- Be respectful and inclusive
-- Welcome newcomers and help them learn
-- Focus on constructive feedback
-- Respect different viewpoints and experiences
-
-## 🏷️ Release Process
-
-1. Update version in relevant files
-2. Update CHANGELOG.md
-3. Create release PR
-4. Tag release after merge
-5. Build and publish Docker images
-6. Create GitHub release with notes
-
-## 📞 Getting Help
-
-- Check existing issues and documentation first
-- Open an issue for bugs or feature requests
-- Join discussions in existing issues
-- Ask questions in issues (we're happy to help!)
-
-Thank you for contributing! 🎉
diff --git a/HELM_HOSTING_GUIDE.md b/HELM_HOSTING_GUIDE.md
deleted file mode 100644
index 4527bdd..0000000
--- a/HELM_HOSTING_GUIDE.md
+++ /dev/null
@@ -1,313 +0,0 @@
-# Hosting Passkey Auth Helm Chart on GitHub
-
-This guide explains how to host your Helm chart on GitHub Pages and make it available via a public Helm repository.
-
-## Prerequisites
-
-- GitHub repository with your Helm chart
-- GitHub Actions enabled
-- GitHub Pages enabled
-
-## Setup Steps
-
-### 1. Repository Structure
-
-Ensure your repository has this structure:
-```
-passkey-auth/
-├── .github/
-│   ├── workflows/
-│   │   └── helm-release.yml
-│   └── cr.yaml
-├── helm/
-│   └── passkey-auth/
-│       ├── Chart.yaml
-│       ├── values.yaml
-│       ├── README.md
-│       ├── templates/
-│       └── examples/
-└── README.md
-```
-
-### 2. Enable GitHub Pages
-
-1. Go to your GitHub repository
-2. Navigate to **Settings** > **Pages**
-3. Under **Source**, select **GitHub Actions**
-4. Save the configuration
-
-### 3. Configure Repository Settings
-
-1. **Enable GitHub Actions**:
-   - Go to **Settings** > **Actions** > **General**
-   - Enable "Allow all actions and reusable workflows"
-
-2. **Set up GitHub Pages permissions**:
-   - Go to **Settings** > **Actions** > **General**
-   - Under "Workflow permissions", select "Read and write permissions"
-   - Check "Allow GitHub Actions to create and approve pull requests"
-
-### 4. Update Chart Configuration
-
-Edit `.github/cr.yaml` to match your repository:
-
-```yaml
-owner: YOUR_GITHUB_USERNAME  # Change this
-git-repo: passkey-auth       # Change if different
-charts-repo: https://YOUR_GITHUB_USERNAME.github.io/passkey-auth
-target-branch: gh-pages
-package-path: .cr-release-packages
-index-path: .cr-index
-skip-existing: true
-```
-
-### 5. Create Your First Release
-
-1. **Tag your first release**:
-   ```bash
-   git tag v0.1.0
-   git push origin v0.1.0
-   ```
-
-2. **Or push changes to trigger workflow**:
-   ```bash
-   git add .
-   git commit -m "Add Helm chart"
-   git push origin main
-   ```
-
-The GitHub Action will automatically:
-- Lint and test your chart
-- Package the chart
-- Create a GitHub release
-- Update the Helm repository index
-- Deploy to GitHub Pages
-
-### 6. Verify the Setup
-
-1. **Check GitHub Actions**:
-   - Go to **Actions** tab in your repository
-   - Verify the "Release Helm Chart" workflow completes successfully
-
-2. **Check GitHub Pages**:
-   - Go to **Settings** > **Pages**
-   - You should see "Your site is published at https://username.github.io/passkey-auth"
-
-3. **Test the Helm repository**:
-   ```bash
-   helm repo add passkey-auth https://YOUR_USERNAME.github.io/passkey-auth
-   helm repo update
-   helm search repo passkey-auth
-   ```
-
-## Using Your Hosted Chart
-
-### Add the Repository
-
-```bash
-helm repo add passkey-auth https://YOUR_USERNAME.github.io/passkey-auth
-helm repo update
-```
-
-### Install the Chart
-
-```bash
-# Basic installation
-helm install my-passkey-auth passkey-auth/passkey-auth
-
-# With custom values
-helm install my-passkey-auth passkey-auth/passkey-auth \
-  --set config.webauthn.rpId=auth.example.com \
-  --set secrets.sessionSecret="your-secure-secret"
-
-# With values file
-helm install my-passkey-auth passkey-auth/passkey-auth \
-  -f values-production.yaml
-```
-
-### Search Available Versions
-
-```bash
-helm search repo passkey-auth --versions
-```
-
-## Maintenance and Updates
-
-### Releasing New Versions
-
-1. **Update Chart.yaml**:
-   ```yaml
-   version: 0.2.0  # Increment version
-   appVersion: "v1.1.0"  # Update app version if needed
-   ```
-
-2. **Commit and push**:
-   ```bash
-   git add helm/passkey-auth/Chart.yaml
-   git commit -m "Bump chart version to 0.2.0"
-   git push origin main
-   ```
-
-3. **The workflow will automatically**:
-   - Package the new version
-   - Create a GitHub release
-   - Update the Helm repository
-
-### Testing Charts Locally
-
-```bash
-# Lint the chart
-helm lint helm/passkey-auth/
-
-# Template the chart (dry run)
-helm template my-passkey-auth helm/passkey-auth/ \
-  --set config.webauthn.rpId=test.local
-
-# Install locally for testing
-helm install test-release helm/passkey-auth/ \
-  --dry-run --debug
-```
-
-## Advanced Configuration
-
-### Custom Domain for Helm Repository
-
-If you want to use a custom domain instead of `username.github.io`:
-
-1. **Set up custom domain in GitHub Pages**:
-   - Go to **Settings** > **Pages**
-   - Add your custom domain (e.g., `charts.example.com`)
-
-2. **Update `.github/cr.yaml`**:
-   ```yaml
-   charts-repo: https://charts.example.com
-   ```
-
-3. **Configure DNS**:
-   - Add CNAME record pointing to `username.github.io`
-
-### Multiple Charts in One Repository
-
-If you have multiple charts:
-
-```
-helm/
-├── passkey-auth/
-│   ├── Chart.yaml
-│   └── ...
-├── another-chart/
-│   ├── Chart.yaml
-│   └── ...
-```
-
-The workflow will automatically detect and release all charts.
-
-### Private Repositories
-
-For private repositories, users will need:
-
-1. **GitHub Personal Access Token**:
-   ```bash
-   helm repo add passkey-auth https://username:TOKEN@username.github.io/passkey-auth
-   ```
-
-2. **Or configure helm with auth**:
-   ```bash
-   helm repo add passkey-auth https://username.github.io/passkey-auth \
-     --username YOUR_USERNAME \
-     --password YOUR_TOKEN
-   ```
-
-## Troubleshooting
-
-### Common Issues
-
-1. **GitHub Actions Fails**:
-   - Check workflow permissions in repository settings
-   - Verify GitHub Pages is enabled
-   - Check if there are syntax errors in the chart
-
-2. **Chart Not Found**:
-   - Verify the repository URL is correct
-   - Check if GitHub Pages deployment completed
-   - Ensure chart name matches directory name
-
-3. **Permission Denied**:
-   - Verify GitHub Actions has write permissions
-   - Check if GitHub Pages is enabled for the repository
-
-### Debug Commands
-
-```bash
-# Check repository status
-helm repo list
-
-# Update repositories
-helm repo update
-
-# Debug template rendering
-helm template my-release helm/passkey-auth/ --debug
-
-# Validate chart
-helm lint helm/passkey-auth/
-
-# Check chart dependencies
-helm dependency list helm/passkey-auth/
-```
-
-## Security Considerations
-
-### Repository Security
-
-1. **Secrets Management**:
-   - Never commit sensitive values to the repository
-   - Use GitHub Secrets for sensitive configuration
-   - Document security requirements in README
-
-2. **Chart Signing** (Optional):
-   ```bash
-   # Generate GPG key for chart signing
-   gpg --gen-key
-
-   # Export public key
-   gpg --armor --export your-email@example.com > public.key
-
-   # Add to chart-releaser config
-   echo "sign: true" >> .github/cr.yaml
-   ```
-
-3. **Dependency Security**:
-   - Regularly update chart dependencies
-   - Use dependency vulnerability scanning
-   - Pin specific versions in production
-
-### Best Practices
-
-1. **Version Management**:
-   - Follow semantic versioning
-   - Update `appVersion` when application changes
-   - Update `version` when chart changes
-
-2. **Documentation**:
-   - Keep README.md updated
-   - Document breaking changes
-   - Provide migration guides
-
-3. **Testing**:
-   - Test charts before releasing
-   - Use CI/CD for automated testing
-   - Validate on different Kubernetes versions
-
-## Example Repository
-
-You can see a complete example at: `https://github.com/YOUR_USERNAME/passkey-auth`
-
-The hosted Helm repository will be available at: `https://YOUR_USERNAME.github.io/passkey-auth`
-
-## Support
-
-If you encounter issues:
-1. Check the GitHub Actions logs
-2. Verify chart syntax with `helm lint`
-3. Review GitHub Pages deployment status
-4. Open an issue in the repository for help
diff --git a/IMPLEMENTATION.md b/IMPLEMENTATION.md
deleted file mode 100644
index f2e515e..0000000
--- a/IMPLEMENTATION.md
+++ /dev/null
@@ -1,122 +0,0 @@
-# 📋 Implementation Summary
-
-## What We've Built
-
-✅ **Complete Passkey Authentication System** with email-based access control
-✅ **SQLite Database** for persistent user storage
-✅ **Email Allowlist System** for controlling who can register
-✅ **Kubernetes Integration** with nginx ingress auth backend
-✅ **Modern Web UI** for user registration and management
-✅ **Production-Ready Deployment** with Docker and Kubernetes manifests
-
-## Key Features Implemented
-
-### 🔐 Email-Based Authentication
-- Users are identified by email addresses (not usernames)
-- Configurable email allowlist for access control
-- Environment variable support for email configuration
-
-### 📧 Email Access Control Options
-
-1. **Open Mode**: Empty allowlist allows any email
-2. **Restricted Mode**: Only allowlisted emails can register
-3. **Combined Security**: Allowlist + manual approval
-
-### 🗄️ Database Architecture (SQLite)
-```sql
--- Users table
-CREATE TABLE users (
-    id INTEGER PRIMARY KEY,
-    email TEXT UNIQUE NOT NULL,     -- Email as primary identifier
-    display_name TEXT NOT NULL,
-    approved BOOLEAN DEFAULT FALSE,
-    created_at DATETIME DEFAULT CURRENT_TIMESTAMP
-);
-
--- Credentials table (WebAuthn keys)
-CREATE TABLE credentials (
-    id BLOB PRIMARY KEY,
-    user_id INTEGER REFERENCES users(id),
-    public_key BLOB NOT NULL,
-    attestation_type TEXT NOT NULL,
-    aaguid BLOB,
-    sign_count INTEGER DEFAULT 0,
-    clone_warning BOOLEAN DEFAULT FALSE,
-    created_at DATETIME DEFAULT CURRENT_TIMESTAMP
-);
-```
-
-### ⚙️ Configuration Options
-
-```yaml
-auth:
-  session_secret: "your-secret-key"
-  require_approval: true           # Admin approval required
-  allowed_emails:                  # Email allowlist
-    - "admin@company.com"
-    - "engineering@company.com"
-```
-
-Or via environment variables:
-```bash
-export ALLOWED_EMAILS="admin@company.com,user1@company.com,user2@company.com"
-export SESSION_SECRET="your-secure-session-secret"
-```
-
-## Files Created/Modified
-
-### Core Application
-- `main.go` - Application entry point
-- `internal/config/` - Configuration management with email allowlist
-- `internal/database/` - SQLite database layer with email-based users
-- `internal/auth/` - WebAuthn implementation
-- `internal/handlers/` - HTTP handlers with email validation
-
-### Web Interface
-- `web/index.html` - Admin UI updated for email addresses
-
-### Deployment
-- `Dockerfile` - Container build
-- `k8s/` - Kubernetes manifests
-- `docker-compose.yml` - Local development
-- `scripts/` - Build and deployment scripts
-
-### Documentation
-- `README.md` - Complete usage guide
-- `PRODUCTION.md` - Production deployment guide
-- `config.example.yaml` - Example configuration
-
-## How It Works
-
-1. **Email Validation**: When a user tries to register, the system checks if their email is in the allowlist (if configured)
-2. **Database Storage**: User data is stored in SQLite with email as the unique identifier
-3. **WebAuthn Integration**: Passkey credentials are linked to the user record
-4. **Session Management**: Authentication sessions use email-based identification
-5. **Nginx Integration**: Auth headers include user email for downstream applications
-
-## Quick Start
-
-```bash
-# 1. Configure email allowlist
-vim config.yaml  # Add your allowed emails
-
-# 2. Start the service
-./scripts/dev.sh
-
-# 3. Register users at http://localhost:8080
-# Only emails in the allowlist can register
-
-# 4. Deploy to Kubernetes
-./scripts/build.sh
-./scripts/deploy.sh
-```
-
-## Security Benefits
-
-- **No passwords stored** - Only WebAuthn public keys
-- **Email-based access control** - Restrict registration to specific domains/emails
-- **Phishing resistant** - WebAuthn is tied to the domain
-- **MFA built-in** - Passkeys require user presence and verification
-- **Session security** - Secure cookie-based sessions
-
-This implementation provides a complete, production-ready passkey authentication system with fine-grained email-based access control, perfect for enterprise environments where you need to restrict access to specific users.
diff --git a/PRODUCTION.md b/PRODUCTION.md
deleted file mode 100644
index 95e8859..0000000
--- a/PRODUCTION.md
+++ /dev/null
@@ -1,287 +0,0 @@
-# Production Deployment Guide
-
-This guide covers deploying Passkey Auth in a production Kubernetes environment.
-
-## Prerequisites
-
-- Kubernetes cluster with nginx ingress controller
-- Domain name with SSL certificate
-- kubectl access to the cluster
-- Docker registry access (optional, for custom builds)
-
-## Step 1: Prepare Configuration
-
-1. **Generate Session Secret**:
-```bash
-openssl rand -base64 32
-```
-
-2. **Update Kubernetes Configuration**:
-
-Edit `k8s/deployment.yaml` and update the ConfigMap:
-
-```yaml
-data:
-  config.yaml: |
-    server:
-      port: "8080"
-      host: "0.0.0.0"
-
-    webauthn:
-      rp_display_name: "Your Company Auth"
-      rp_id: "auth.yourcompany.com"        # Your auth domain
-      rp_origins:
-        - "https://auth.yourcompany.com"    # Your auth URL
-        - "https://app.yourcompany.com"     # Your app URLs
-
-    database:
-      path: "/data/passkey-auth.db"
-
-    cors:
-      allowed_origins:
-        - "https://auth.yourcompany.com"
-        - "https://app.yourcompany.com"
-
-    auth:
-      session_secret: "YOUR_GENERATED_SECRET_HERE"
-      require_approval: true
-```
-
-## Step 2: Deploy to Kubernetes
-
-1. **Create Namespace**:
-```bash
-kubectl apply -f k8s/namespace.yaml
-```
-
-2. **Deploy Application**:
-```bash
-kubectl apply -f k8s/deployment.yaml
-```
-
-3. **Verify Deployment**:
-```bash
-kubectl get pods -n passkey-auth
-kubectl logs -f deployment/passkey-auth -n passkey-auth
-```
-
-## Step 3: Configure SSL/TLS
-
-Create an ingress with SSL termination:
-
-```yaml
-apiVersion: networking.k8s.io/v1
-kind: Ingress
-metadata:
-  name: passkey-auth-ingress
-  namespace: passkey-auth
-  annotations:
-    cert-manager.io/cluster-issuer: "letsencrypt-prod"  # If using cert-manager
-    nginx.ingress.kubernetes.io/ssl-redirect: "true"
-spec:
-  tls:
-  - hosts:
-    - auth.yourcompany.com
-    secretName: passkey-auth-tls
-  rules:
-  - host: auth.yourcompany.com
-    http:
-      paths:
-      - path: /
-        pathType: Prefix
-        backend:
-          service:
-            name: passkey-auth-service
-            port:
-              number: 80
-```
-
-## Step 4: Configure Your Application Ingress
-
-Update your application's ingress to use passkey auth:
-
-```yaml
-apiVersion: networking.k8s.io/v1
-kind: Ingress
-metadata:
-  name: your-app-ingress
-  annotations:
-    # Auth configuration
-    nginx.ingress.kubernetes.io/auth-url: "http://passkey-auth-service.passkey-auth.svc.cluster.local/auth"
-    nginx.ingress.kubernetes.io/auth-signin: "https://auth.yourcompany.com"
-    nginx.ingress.kubernetes.io/auth-response-headers: "X-Auth-User,X-Auth-User-ID"
-
-    # SSL configuration
-    cert-manager.io/cluster-issuer: "letsencrypt-prod"
-    nginx.ingress.kubernetes.io/ssl-redirect: "true"
-spec:
-  tls:
-  - hosts:
-    - app.yourcompany.com
-    secretName: your-app-tls
-  rules:
-  - host: app.yourcompany.com
-    http:
-      paths:
-      - path: /
-        pathType: Prefix
-        backend:
-          service:
-            name: your-app-service
-            port:
-              number: 80
-```
-
-## Step 5: Set Up Monitoring (Optional)
-
-### Health Checks
-
-The service includes health checks at `/health`. Configure monitoring:
-
-```yaml
-# Add to your monitoring stack
-- job_name: 'passkey-auth'
-  static_configs:
-  - targets: ['passkey-auth-service.passkey-auth.svc.cluster.local:80']
-  metrics_path: '/health'
-```
-
-### Log Aggregation
-
-Configure log forwarding to your logging system:
-
-```bash
-kubectl logs -f deployment/passkey-auth -n passkey-auth | your-log-forwarder
-```
-
-## Step 6: Backup Strategy
-
-### Database Backup
-
-Set up regular backups of the SQLite database:
-
-```bash
-# Create a backup cronjob
-apiVersion: batch/v1
-kind: CronJob
-metadata:
-  name: passkey-auth-backup
-  namespace: passkey-auth
-spec:
-  schedule: "0 2 * * *"  # Daily at 2 AM
-  jobTemplate:
-    spec:
-      template:
-        spec:
-          containers:
-          - name: backup
-            image: alpine
-            command:
-            - /bin/sh
-            - -c
-            - |
-              cp /data/passkey-auth.db /backup/passkey-auth-$(date +%Y%m%d).db
-              # Upload to your backup storage
-            volumeMounts:
-            - name: data
-              mountPath: /data
-            - name: backup
-              mountPath: /backup
-          restartPolicy: OnFailure
-          volumes:
-          - name: data
-            persistentVolumeClaim:
-              claimName: passkey-auth-storage
-          - name: backup
-            # Configure your backup storage volume
-```
-
-## Security Checklist
-
-- [ ] HTTPS enforced for all endpoints
-- [ ] Session secret is randomly generated and secure
-- [ ] CORS origins are specifically configured (not "*")
-- [ ] WebAuthn RP ID matches your domain exactly
-- [ ] Network policies restrict pod-to-pod communication
-- [ ] Regular security updates applied
-- [ ] Database backups are encrypted and tested
-- [ ] Access logs are monitored
-- [ ] Kubernetes RBAC is properly configured
-
-## Troubleshooting
-
-### Common Production Issues
-
-1. **WebAuthn Registration Fails**:
-   - Verify RP ID matches domain exactly
-   - Ensure HTTPS is properly configured
-   - Check browser developer console for errors
-
-2. **Auth Backend Returns 502**:
-   - Verify service is running: `kubectl get pods -n passkey-auth`
-   - Check service connectivity: `kubectl get svc -n passkey-auth`
-   - Review nginx ingress logs
-
-3. **Session Issues**:
-   - Verify session secret is consistent across restarts
-   - Check cookie domain settings
-   - Ensure persistent storage is working
-
-### Debug Commands
-
-```bash
-# Check service status
-kubectl get all -n passkey-auth
-
-# View logs
-kubectl logs -f deployment/passkey-auth -n passkey-auth
-
-# Test auth endpoint
-kubectl exec -it deployment/passkey-auth -n passkey-auth -- wget -O- http://localhost:8080/health
-
-# Check ingress
-kubectl describe ingress -n passkey-auth
-
-# Port forward for testing
-kubectl port-forward svc/passkey-auth-service 8080:80 -n passkey-auth
-```
-
-## Scaling Considerations
-
-### High Availability
-
-For high availability, consider:
-
-1. **Multiple Replicas**: Increase replica count in deployment
-2. **Session Storage**: Use Redis for shared session storage
-3. **Database**: Consider PostgreSQL for better concurrent access
-4. **Load Balancing**: Ensure proper session affinity
-
-### Performance Tuning
-
-1. **Resource Limits**: Adjust based on usage patterns
-2. **Database Optimization**: Regular VACUUM for SQLite
-3. **Caching**: Add caching layer for frequently accessed data
-
-## Updates and Maintenance
-
-### Rolling Updates
-
-```bash
-# Update the image
-kubectl set image deployment/passkey-auth passkey-auth=passkey-auth:v1.1.0 -n passkey-auth
-
-# Monitor rollout
-kubectl rollout status deployment/passkey-auth -n passkey-auth
-
-# Rollback if needed
-kubectl rollout undo deployment/passkey-auth -n passkey-auth
-```
-
-### Database Migrations
-
-For schema changes, implement migration scripts and run them during maintenance windows.
-
----
-
-This production guide ensures a secure, reliable deployment of Passkey Auth in your Kubernetes environment.
diff --git a/README.md b/README.md
index 40a6e1b..33889f9 100644
--- a/README.md
+++ b/README.md
@@ -27,18 +27,8 @@ A WebAuthn-based passkey authentication provider that integrates ingress control
 helm repo add passkey-auth https://wahyd4.github.io/passkey-auth
 helm repo update
 
-# Install with your configuration
-helm install my-passkey-auth passkey-auth/passkey-auth \
-  --set config.webauthn.rpId=auth.example.com \
-  --set config.webauthn.rpOrigins="{https://auth.example.com}" \
-  --set config.cors.allowedOrigins="{https://*.example.com}" \
-  --set config.auth.cookieDomain=".example.com" \
-  --set config.auth.allowedEmails="{admin@example.com}" \
-  --set ingress.hosts[0].host=auth.example.com \
-  --set secrets.sessionSecret="your-secure-random-secret-key"
-
-# Or use a values file
-helm install my-passkey-auth passkey-auth/passkey-auth -f values-production.yaml
+# Install with your values
+helm upgrade --install my-passkey-auth -n home-apps -f my-values.yaml  passkey-auth/passkey-auth
 ```
 
 See the [Helm Chart README](helm/passkey-auth/README.md) for detailed configuration options.
diff --git a/helm/passkey-auth/README.md b/helm/passkey-auth/README.md
index 525e7d8..844b157 100644
--- a/helm/passkey-auth/README.md
+++ b/helm/passkey-auth/README.md
@@ -11,10 +11,7 @@ This chart deploys a secure, passwordless authentication service using WebAuthn/
 ```bash
 helm repo add passkey-auth https://wahyd4.github.io/passkey-auth
 helm repo update
-helm install my-passkey-auth passkey-auth/passkey-auth \
-  --set config.webauthn.rpId=auth.example.com \
-  --set config.webauthn.rpOrigins="{https://auth.example.com}" \
-  --set secrets.sessionSecret="your-very-long-random-secret-key-here"
+helm upgrade --install my-passkey-auth -n home-apps -f my-values.yaml  passkey-auth/passkey-auth
 ```
 
 ## Prerequisites
@@ -140,76 +137,6 @@ secrets:
   existingSecret: "external-passkey-secrets"  # Reference external secret
 ```
 
-### Image Pull Secrets
-
-The chart uses the public GitHub Container Registry by default, but you may need to configure image pull secrets for:
-
-- **Private container registries**
-- **GitHub Container Registry with authentication** (for private repositories or rate limiting)
-- **Other private registry providers**
-
-#### Creating Image Pull Secrets
-
-**For GitHub Container Registry:**
-
-```bash
-# Create a GitHub Personal Access Token with 'read:packages' permission
-# Then create the secret:
-kubectl create secret docker-registry github-registry-secret \
-  --docker-server=ghcr.io \
-  --docker-username=your-github-username \
-  --docker-password=your-github-token \
-  --docker-email=your-email@example.com
-```
-
-**For Docker Hub:**
-
-```bash
-kubectl create secret docker-registry dockerhub-secret \
-  --docker-server=docker.io \
-  --docker-username=your-dockerhub-username \
-  --docker-password=your-dockerhub-password \
-  --docker-email=your-email@example.com
-```
-
-**For private registry:**
-
-```bash
-kubectl create secret docker-registry private-registry-secret \
-  --docker-server=your-registry.example.com \
-  --docker-username=your-username \
-  --docker-password=your-password \
-  --docker-email=your-email@example.com
-```
-
-#### Configuring Image Pull Secrets in values.yaml
-
-**Single image pull secret:**
-
-```yaml
-imagePullSecrets:
-  - name: github-registry-secret
-```
-
-**Multiple image pull secrets:**
-
-```yaml
-imagePullSecrets:
-  - name: github-registry-secret
-  - name: private-registry-secret
-```
-
-**Complete example for private GitHub repository:**
-
-```yaml
-image:
-  repository: ghcr.io/your-org/passkey-auth
-  tag: "v1.0.0"
-  pullPolicy: IfNotPresent
-
-imagePullSecrets:
-  - name: github-registry-secret
-```
 
 ## Parameters