DEV Community: Julien Béranger

Publish encrypted, shareable docs from your terminal (or Claude Code) with Fileverse

Julien Béranger — Wed, 08 Jul 2026 15:30:43 +0000

I often need to publish some notes somewhere, just to keep it or to hand it to someone, and I always found it painful to interrupt my work, go create a Google doc and copy-paste the content. I'm lazy as a good dev should, so here I am with the solution.

In you terminal, you type:

share SECURITY_AUDIT_JAN_15.md

or in Claude Code:

/share that doc

And it returns this shareable link:

https://docs.fileverse.io/0x21b9d1591b1440BA8D3f2470E18f7d9f29e4E345/10#key=-GcNYlM5tVR9Kh2LNfFMZBFgGkgMLR6gHXIFKrtIZ0kCvAX5spcEpV-clnfqjVzE

I don't even know if this is feasible with Google Docs and I don't really care because, in case you haven't noticed yet, Fileverse is simply the best alternative in town.

dDocs are end-to-end encrypted documents: content is encrypted client-side before it ever leaves your machine, references are anchored onchain, and sharing works through a link that carries the decryption key in the URL fragment (the part after #, which browsers never send to servers). No account required for readers. No ads, no tracking, no platform lock-in.

The Fileverse API makes this scriptable: it's a small self-hosted server you run locally. By the end of this tutorial you'll be able to do this from any project on your machine:

share SECURITY_AUDIT_JAN_15.md

...and get back:

Published: SECURITY_AUDIT_JAN_15.md
ddocId: 5dKEgEgsSbFVrCsmSv4yf4
link: [https://docs.fileverse.io/0x21b9d1591b1440BA8D3f2470E18f7d9f29e4E345/10#key=-GcNYlM5tVR9Kh2LNfFMZBFgGkgMLR6gHXIFKrtIZ0kCvAX5spcEpV-clnfqjVzE](https://docs.fileverse.io/0x21b9d1591b1440BA8D3f2470E18f7d9f29e4E345/10#key=-GcNYlM5tVR9Kh2LNfFMZBFgGkgMLR6gHXIFKrtIZ0kCvAX5spcEpV-clnfqjVzE)

That link is instantly shareable with anyone. Bonus: it also works as a /share slash command in Claude Code.

Note: you do NOT deploy this API anywhere. It runs on 127.0.0.1. That's the point — encryption happens on your device.

Prerequisites

Node.js v18+ (node -v to check)
macOS or Linux with bash, curl, and python3 (all preinstalled on macOS)
git
Optionally: Claude Code for the slash-command part

Step 1 — Fileverse signup

Go to ddocs.new
Create your account / portal (a portal is your onchain document space)

Step 2 — Get your API key

In ddocs.new, open Settings
Enable Developer Mode
Generate your API key and copy it

Treat this key like a password. It never lives in a script or in git — only in a local config file.

Step 3 — Install and run the local API server

npm install -g @fileverse/api
fileverse-api --apiKey="YOUR_API_KEY"

The first run fetches your key data, writes config to ~/.fileverse/.env, runs database migrations, and starts the API server (port 8001) plus a background worker that publishes your docs onchain.

You should see:

✓ Fileverse API is running!

  API Server: http://127.0.0.1:8001
  Worker:     Active

Troubleshooting: `ERR_MODULE_NOT_FOUND: Cannot find package 'y-protocols'`

At the time of writing, the npm package can hit a missing-dependency error on some setups (like mine!). Fix:

npm install -g y-protocols yjs
npm uninstall -g @fileverse/api
npm install -g @fileverse/api

Then run fileverse-api --apiKey="..." again.

Step 4 — Install `share`

Clone the dotfiles repo and run its installer:

git clone https://github.com/julienbrg/dotfiles.git ~/dotfiles
cd ~/dotfiles
./install.sh

install.sh symlinks two files into place: the share command (into ~/.local/bin/share) and the Claude Code /share command (into ~/.claude/commands/share.md). It's safe to re-run — anything already at those paths gets backed up as .bak first.

Make sure ~/.local/bin is on your PATH (zsh shown; use ~/.bashrc for bash):

echo 'export PATH="$HOME/.local/bin:$PATH"' >> ~/.zshrc
source ~/.zshrc

What `share` does behind the scenes

share <file> is a single command, but it handles the whole publish flow for you:

Reads your API key from ~/.fileverse/.env — nothing is ever hardcoded or passed on the command line.
Checks whether the local server is already running. If not, it starts fileverse-api itself and waits (up to 45s) for it to become healthy. If it was already running, share leaves it alone — it only ever stops a server it started itself.
Uploads the file to the local API, which encrypts it client-side and kicks off the onchain sync.
Polls until the sync completes, retrying once automatically if a sync event fails.
Prints the shareable link, then shuts back down any server it started in step 2.

It also remembers every file it publishes (in ~/.fileverse/shared.tsv), so re-sharing the same file updates the existing doc instead of creating a new one (more on this in Step 6).

A couple of details worth knowing if something goes sideways:

Parsing is done in Python rather than jq, because the API echoes your document content back in its response, and markdown can contain raw control characters that break jq. Python's JSON parser handles it fine.
If a run gets interrupted mid-sync, nothing is lost — sync state lives in a local SQLite database, so the next share run just picks up where it left off.

Step 5 — Verify setup

# 1. Server config exists?
cat ~/.fileverse/.env        # should show API_KEY=... and DB_PATH=...

# 2. Command is found and executable?
which share                  # → /Users/you/.local/bin/share

# 3. Publish something!
cd ~/any-project
share SECURITY_AUDIT_JAN_15.md

Expected output:

Created ddoc o84yyFHUropP47AYiAqpXe, waiting for onchain sync...
Published: SECURITY_AUDIT_JAN_15.md
ddocId: o84yyFHUropP47AYiAqpXe
link: [https://docs.fileverse.io/0x21b9d1591b1440BA8D3f2470E18f7d9f29e4E345/10#key=-GcNYlM5tVR9Kh2LNfFMZBFgGkgMLR6gHXIFKrtIZ0kCvAX5spcEpV-clnfqjVzE](https://docs.fileverse.io/0x21b9d1591b1440BA8D3f2470E18f7d9f29e4E345/10#key=-GcNYlM5tVR9Kh2LNfFMZBFgGkgMLR6gHXIFKrtIZ0kCvAX5spcEpV-clnfqjVzE)

Open the link in a browser — your document, decrypted client-side.

Sharing model: the link is view-only, for everyone including you — it carries the decryption key, not edit rights. Anyone with the link can read the doc, so treat the link itself as the secret, and remember there's no easy "unshare" once it's out.

One thing to know: docs published through the API don't join your regular file list at ddocs.new — once you've opened a link they show up under "Recently accessed", but view-only, same as for anyone else with the link. Their edit keys live only in the local API database (~/.fileverse/fileverse-api.db), so the browser app can't edit them. To change a published doc, update it from your machine — see the next step.

Step 6 — Updating a published doc

share keeps a small ledger of everything it has published (~/.fileverse/shared.tsv). Re-run it on a file you've already shared, and instead of creating a new doc it updates the existing one in place — the link stays the same:

share SECURITY_AUDIT_JAN_15.md

Already published as ddoc o84yyFHUropP47AYiAqpXe — updating it, link stays the same.
Updated ddoc o84yyFHUropP47AYiAqpXe, waiting for on-chain sync...
Updated: SECURITY_AUDIT_JAN_15.md
ddocId: o84yyFHUropP47AYiAqpXe
link: https://docs.fileverse.io/0x21b9...#key=zMUB4xQb...

Files are tracked by absolute path, so a README.md in one project and a README.md in another are (correctly) two different docs.

For a doc published before the ledger existed, pass its ddocId explicitly once — that updates the doc and records the mapping, so from then on the plain share <file> does the right thing:

share SECURITY_AUDIT_JAN_15.md o84yyFHUropP47AYiAqpXe

Lost a ddocId? The API package also installs a ddctl CLI — ddctl list shows everything you've published, and ddctl update <ddocId> even opens the doc in your $EDITOR.

Step 7 — Claude Code `/share` command

install.sh already symlinked this in Step 4, so /share works out of the box in every project. It's a markdown file (~/.claude/commands/share.md) that delegates entirely to the share script — Claude runs one Bash call, and only the ~4-line result (not your whole document) enters the conversation. Faster, cheaper, and deterministic.

/share SECURITY_AUDIT_JAN_15.md

If Claude Code prompts for permission the first time, pick "Yes, and don't ask again" — that's expected the first time you use any new command, and it won't ask again after that.

Make it your own

This tutorial points at my own dotfiles repo so you can try share immediately. To keep your own copy under your control long-term: fork julienbrg/dotfiles (or just copy bin/share and claude/commands/share.md into your own dotfiles repo), point install.sh at your fork, and push. Same install.sh pattern works on any new machine:

git clone git@github.com:YOUR_USERNAME/dotfiles.git ~/dotfiles
cd ~/dotfiles && ./install.sh
npm install -g @fileverse/api
fileverse-api --apiKey="YOUR_KEY"   # regenerate a key per machine

⚠️ The one rule that matters: never commit secrets. share reads the API key from ~/.fileverse/.env at runtime — that file stays outside the repo, and install.sh never touches it. If you ever paste a key into a chat, an issue, or a commit, regenerate it in ddocs.new Settings → Developer Mode. Keys are cheap; leaked keys are not.

Recap

Piece	Location	Purpose
API key + config	`~/.fileverse/.env`	Secrets, never in git
`share` script	`dotfiles/bin/share` → symlinked to `~/.local/bin/share`	Publish from any terminal
Claude command	`dotfiles/claude/commands/share.md` → symlinked to `~/.claude/commands/share.md`	`/share <file> [ddocId]` in Claude Code
dDocs UI	ddocs.new	Account + API keys (API-published docs appear view-only, under "Recently accessed")

Happy sharing! 🚀

Built with the Fileverse API (AGPL-3.0). Not affiliated with Fileverse — just a fan of encrypted, self-hosted publishing.

Getting Started with Genji: A Web3 App Starter with Passkey Authentication

Julien Béranger — Tue, 03 Mar 2026 11:50:46 +0000

Hello Anon!

Genji is a Next.js starter template that makes it easy to build Web3 apps with passkey authentication. This template gives you a production-ready foundation that handles security and accessibility while keeping user privacy front and center.

What's in it?

Genji integrates the following technologies:

w3pk — Passkey authentication framework
Next.js — React framework for production apps
Ethers — Web3 library for blockchain interaction
Chakra UI — Component library for user interface
WCAG 2.1 AA compliance — Ensures accessibility for everyone

Check out the live demo at https://genji.w3hc.org.

Privacy-Friendly Architecture

Genji takes a privacy-first approach to authentication:

No password storage: Passkeys eliminate the need for password databases, removing a common attack vector
Device-bound credentials: Authentication credentials stay on the user's device and are never sent to servers
No tracking: No need for email addresses, phone numbers, or other personally identifiable information
User control: Users stay in full control of their credentials and can revoke access anytime
Minimal data collection: The app only stores the public key for each account, keeping things private while staying secure

Installation and Setup

Step 1: Create Your Repository

To create your own instance of the Genji template:

Head to the Genji GitHub repository
Click "Use this template" to create a new repository
Give your repository a name

Step 2: Customize the Template

After cloning your repository, run the customization script:

pnpm customize

This script will:

Remove default Genji branding
Set up project-specific configurations
Self-destruct when it's done

Step 3: Install Dependencies

Install the required packages:

pnpm i

Step 4: Start the Development Server

Fire up the dev server:

pnpm dev

Your app will be running at http://localhost:3000.

Now log in and try signing a message on the homepage. Once you're logged in, you don't need to confirm anything to sign the message: w3pk handles it seamlessly using your passkey-derived wallet.

Step 5: Configure Security Level

w3pk offers four security levels for passkey authentication. We recommend STANDARD, which balances security and user experience:

PRIMARY: Requires authentication for every single action, including transaction confirmations. Maximum security but requires the most user interaction.
STRICT: Requires authentication for most operations. Good for high-security apps where user inconvenience is acceptable.
STANDARD (recommended): Requires authentication for login but keeps the session active for what comes next. Users don't need to re-authenticate for each transaction. This gives you the best balance between security and usability for most apps.
YOLO: Minimal authentication requirements. Only for development or low-stakes apps where security isn't a primary concern.

STANDARD is recommended because it cuts out repeated authentication while keeping solid security controls. Users can interact with your app smoothly without compromising account security.

There are a few app examples here if you need some inspiration. Genji can be used for all kinds of apps.

Understanding Passkey Authentication

Passkeys are a modern authentication standard that use device-level security like biometric sensors (Face ID, fingerprint) or device PINs. This approach gets rid of traditional password management and seed phrase storage. The authentication process relies on public-key cryptography, where the private key stays securely on the user's device and is never transmitted.

Best Practices

Documentation: Check out the /docs folder for implementation context and design guidelines
Build Verification: Set up w3pk build verification to ensure code integrity
Security Inspection: Enable security inspection so your users can verify what's happening in your app
Accessibility: Keep WCAG 2.1 AA compliance throughout development

Support and Resources

Need help?

Submit issues on the GitHub repository
Check the complete w3pk docs
Contact Julien

Conclusion

You now have everything you need to build Web3 apps using the Genji template with passkey authentication. The template gives you a privacy-focused, accessible, and secure foundation for building modern decentralized apps.

Deploy a Next.js app to an Infomaniak Ubuntu VPS

Julien Béranger — Mon, 20 Oct 2025 12:51:06 +0000

This guide walks you through deploying a Next.js application to an Infomaniak Ubuntu VPS with automatic CI/CD using GitHub Actions.

Prerequisites

A domain name with DNS access
A GitHub account
VS Code installed on your local machine (for remote development)

0. Order Your Infomaniak VPS

0.1 Choose Your Plan

Go to Infomaniak VPS Order Page
Recommended plan: VPS Start at 3.60 € / month
- 1 vCore
- 2 GB RAM
- 20 GB SSD
- Perfect for small to medium Next.js applications

0.2 VPS Configuration

During the order process:

Operating System: Select Ubuntu 24.04 LTS
Datacenter: Choose the location closest to your users (Geneva or Zurich recommended)
SSH Key (optional but recommended): Add your public SSH key for secure access
Hostname: Give your VPS a meaningful name (e.g., my-nextjs-app)

0.3 Complete Your Order

Review your configuration
Complete the payment process
You'll receive an email with:
- VPS IP address
- Root password (if you didn't add an SSH key)
- Access to Infomaniak Manager

0.4 Access Infomaniak Manager

Log in to manager.infomaniak.com
Navigate to Web & Domain → VPS
Select your newly created VPS
Note your VPS IP address (you'll need it throughout this guide)

1. Infomaniak Firewall Configuration

Before connecting to your VPS, configure the firewall in the Infomaniak Manager interface.

1.1 Access Firewall Settings

In Infomaniak Manager, go to your VPS
Click on Firewall in the left sidebar
Click Add Rule to create new firewall rules

1.2 Required Firewall Rules

Create the following rules (in this order):

Rule 1: SSH Access

Protocol: TCP
Port: 22
Source: Your IP address (or 0.0.0.0/0 for access from anywhere)
Action: Accept
Description: SSH access

Rule 2: HTTP Access

Protocol: TCP
Port: 80
Source: 0.0.0.0/0 (anywhere)
Action: Accept
Description: HTTP traffic

Rule 3: HTTPS Access

Protocol: TCP
Port: 443
Source: 0.0.0.0/0 (anywhere)
Action: Accept
Description: HTTPS traffic

Rule 4: Ping/ICMP (optional)

Protocol: ICMP
Source: 0.0.0.0/0
Action: Accept
Description: Ping requests

1.3 Verify Firewall Status

Ensure the firewall is Enabled
Rules should be listed in order
Save your configuration

Note: The Infomaniak firewall works at the network level before your VPS. You'll also configure UFW (Ubuntu's firewall) later for an additional layer of security.

2. VS Code SSH Configuration

Configure VS Code for remote development on your VPS.

2.1 Install Remote SSH Extension

Open VS Code
Go to Extensions (Ctrl+Shift+X or Cmd+Shift+X)
Search for "Remote - SSH"
Install the extension by Microsoft

2.2 Generate SSH Key (if you don't have one)

On macOS/Linux:

ssh-keygen -t ed25519 -C "your-email@example.com"
# Press Enter to accept default location (~/.ssh/id_ed25519)
# Set a passphrase (optional but recommended)

On Windows (PowerShell):

ssh-keygen -t ed25519 -C "your-email@example.com"
# Press Enter to accept default location

2.3 Copy SSH Key to VPS

First-time connection:

ssh-copy-id your-username@your-vps-ip
# Enter the password provided by Infomaniak

Alternative method (if ssh-copy-id is not available):

# Display your public key
cat ~/.ssh/id_ed25519.pub

# Then manually add it to your VPS:
ssh your-username@your-vps-ip
mkdir -p ~/.ssh
nano ~/.ssh/authorized_keys
# Paste your public key, save and exit
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
exit

2.4 Configure VS Code SSH

In VS Code, press Ctrl+Shift+P (or Cmd+Shift+P on macOS)
Type "Remote-SSH: Open SSH Configuration File"
Select your SSH config file (usually ~/.ssh/config)
Add this configuration:

Host infomaniak-vps
    HostName your-vps-ip
    User your-username
    Port 22
    IdentityFile ~/.ssh/id_ed25519
    ServerAliveInterval 60
    ServerAliveCountMax 3

Replace:

your-vps-ip with your actual VPS IP address
your-username with your VPS username

2.5 Connect to VPS from VS Code

Press Ctrl+Shift+P (or Cmd+Shift+P)
Type "Remote-SSH: Connect to Host"
Select infomaniak-vps
VS Code will open a new window connected to your VPS
You can now browse files and use the integrated terminal

2.6 VS Code Tips for Remote Development

Open folder: Click "Open Folder" and select ~/w3pk-playground
Terminal: Use Ctrl+ to open integrated terminal
Extensions: Install extensions on the remote server (Node.js, ESLint, etc.)
Port forwarding: VS Code automatically forwards ports - useful for testing

3. Fork the Repository

Go to https://github.com/w3hc/w3pk-playground
Click the Fork button in the top right
Clone your forked repository to your local machine:

git clone https://github.com/YOUR_USERNAME/w3pk-playground.git
cd w3pk-playground

4. VPS Initial Setup

4.1 Connect to your VPS

Via VS Code (recommended):

Use the Remote-SSH connection you configured above

Via terminal:

ssh your-username@your-vps-ip

4.2 Update System

sudo apt update && sudo apt upgrade -y

4.3 Install Node.js via NVM

# Install NVM
curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.0/install.sh | bash

# Reload shell configuration
source ~/.bashrc

# Install Node.js (latest LTS)
nvm install --lts

# Verify installation
node -v
npm -v

4.4 Install pnpm

npm install -g pnpm

4.5 Install PM2 (Process Manager)

pnpm add -g pm2

# Setup PM2 to start on system reboot
pm2 startup
# Follow the instructions provided by the command

4.6 Clone your repository on the VPS

cd ~
git clone https://github.com/YOUR_USERNAME/w3pk-playground.git
cd w3pk-playground

4.7 Install dependencies and build

pnpm install
pnpm build

4.8 Start the app with PM2

pm2 start pnpm --name "your-app-name" -- start
pm2 save

Verify it's running:

pm2 list
pm2 logs your-app-name

5. Domain and DNS Configuration

5.1 Configure DNS

In your domain provider's DNS settings (e.g., Infomaniak DNS panel):

Add an A Record:
- Name: subdomain (e.g., app for app.yourdomain.com)
- Type: A
- Value: Your VPS IP address
- TTL: 300 (or default)
Wait for DNS propagation (can take up to 24 hours, usually 5-15 minutes)

7.2 Verify DNS

dig subdomain.yourdomain.com +short
# Should return your VPS IP

6. Nginx Configuration

6.1 Install Nginx

sudo apt update
sudo apt install nginx -y

6.2 Create Nginx configuration

sudo nano /etc/nginx/sites-available/your-app

Add this configuration:

server {
    listen 80;
    listen [::]:80;
    server_name subdomain.yourdomain.com;

    location / {
        proxy_pass http://localhost:3000;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection 'upgrade';
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_cache_bypass $http_upgrade;
    }
}

6.3 Enable the site

# Create symbolic link
sudo ln -s /etc/nginx/sites-available/your-app /etc/nginx/sites-enabled/

# Test configuration
sudo nginx -t

# Reload Nginx
sudo systemctl reload nginx

7. SSL Certificate Setup

7.1 Install Certbot

sudo apt update
sudo apt install certbot python3-certbot-nginx -y

7.2 Obtain SSL certificate

sudo certbot --nginx -d subdomain.yourdomain.com

Follow the prompts:

Enter your email address
Agree to terms of service
Choose to redirect HTTP to HTTPS (recommended)

7.3 Verify SSL certificate

# Check certificate status
sudo certbot certificates

# Test auto-renewal
sudo certbot renew --dry-run

Your site should now be accessible at https://subdomain.yourdomain.com

8. UFW Firewall Configuration (Additional Layer)

Configure Ubuntu's UFW firewall for additional security.

# Install UFW (usually pre-installed)
sudo apt install ufw -y

# Allow SSH (IMPORTANT: do this first!)
sudo ufw allow 22/tcp

# Allow HTTP and HTTPS
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

# Enable UFW
sudo ufw enable

# Check status
sudo ufw status verbose

Important: Always allow SSH (port 22) before enabling UFW, or you'll lose access to your VPS!

9. GitHub Actions CI/CD Setup

9.1 Create SSH key for GitHub Actions

On your VPS:

# Generate SSH key WITHOUT passphrase (important!)
ssh-keygen -t ed25519 -C "github-actions" -f ~/.ssh/github-actions -N ""

# Add public key to authorized_keys
cat ~/.ssh/github-actions.pub >> ~/.ssh/authorized_keys

# Set correct permissions
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chmod 600 ~/.ssh/github-actions

9.2 Copy the private key

cat ~/.ssh/github-actions

Copy the entire output including -----BEGIN and -----END lines.

9.3 Create GitHub workflow file

In your local repository, create .github/workflows/deploy.yml:

name: Deploy to VPS

on:
  push:
    branches:
      - main

jobs:
  deploy:
    runs-on: ubuntu-latest

    steps:
      - name: Deploy to VPS
        uses: appleboy/ssh-action@v1.0.0
        with:
          host: ${{ secrets.VPS_HOST }}
          username: ${{ secrets.VPS_USERNAME }}
          key: ${{ secrets.VPS_SSH_KEY }}
          script: |
            export NVM_DIR="$HOME/.nvm"
            [ -s "$NVM_DIR/nvm.sh" ] && \. "$NVM_DIR/nvm.sh"
            export PATH="$HOME/.local/share/pnpm:$PATH"
            cd ~/w3pk-playground
            git pull origin main
            pnpm install
            pnpm build
            pm2 restart your-app-name
            pm2 save

9.4 Add GitHub Secrets

Go to your GitHub repository:

Click Settings → Secrets and variables → Actions
Click New repository secret
Add three secrets:

VPS_HOST

your-vps-ip-address

VPS_USERNAME

your-vps-username

VPS_SSH_KEY

(paste the entire private key from ~/.ssh/github-actions)

9.5 Commit and push

git add .github/workflows/deploy.yml
git commit -m "Add CI/CD workflow"
git push origin main

10. Test Your Deployment

Make a change to your code
Commit and push to the main branch
Go to your GitHub repository → Actions tab
Watch the deployment workflow run
Visit https://subdomain.yourdomain.com to see your changes

Useful Commands

PM2 Management

pm2 list                    # List all apps
pm2 logs your-app-name     # View logs
pm2 restart your-app-name  # Restart app
pm2 stop your-app-name     # Stop app
pm2 delete your-app-name   # Remove app
pm2 monit                  # Monitor all apps

Nginx Management

sudo nginx -t              # Test configuration
sudo systemctl reload nginx # Reload configuration
sudo systemctl restart nginx # Restart Nginx
sudo systemctl status nginx # Check status

SSL Certificate Management

sudo certbot certificates  # List all certificates
sudo certbot renew        # Renew certificates
sudo certbot delete       # Delete a certificate

Checking Open Ports

sudo ss -tulpn             # Show all listening ports
sudo lsof -i :3000        # Check specific port

Firewall Management

# Infomaniak Firewall: Manage via Infomaniak Manager web interface

# UFW Firewall
sudo ufw status verbose    # Check UFW status
sudo ufw allow 3000/tcp   # Allow specific port
sudo ufw deny 3000/tcp    # Deny specific port
sudo ufw delete allow 3000/tcp  # Remove rule
sudo ufw reset            # Reset all rules (careful!)

Troubleshooting

Cannot Connect via SSH

Check Infomaniak firewall: Ensure port 22 is allowed
Check UFW: Run sudo ufw allow 22/tcp if you have terminal access
Use Infomaniak Console: Access your VPS through the web console in Infomaniak Manager
Verify IP: Ensure you're using the correct VPS IP address

502 Bad Gateway

Check if your app is running: pm2 list
Check app logs: pm2 logs your-app-name
Verify the port in Nginx config matches your app's port
Restart the app: pm2 restart your-app-name

Build Fails in CI/CD

Check GitHub Actions logs for specific errors
Verify SSH key is correct in GitHub secrets
Ensure NVM and pnpm paths are correct in workflow
Test commands manually on VPS first

SSL Certificate Issues

Verify DNS is pointing to your VPS: dig subdomain.yourdomain.com
Check if port 80 and 443 are open in both Infomaniak firewall and UFW
Review Certbot logs: sudo cat /var/log/letsencrypt/letsencrypt.log

Permission Denied Errors

# Fix SSH permissions
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chmod 600 ~/.ssh/github-actions

# Fix file ownership
sudo chown -R your-username:your-username ~/w3pk-playground

Port Already in Use

# Check what's using the port
sudo lsof -i :3000

# Kill the process if needed
sudo kill -9 PID

Security Best Practices

Two-Layer Firewall:
- Infomaniak firewall (network level)
- UFW firewall (system level)
SSH Security:

   sudo nano /etc/ssh/sshd_config
   # Set: PasswordAuthentication no
   # Set: PermitRootLogin no
   sudo systemctl restart sshd

Regular Updates:

   sudo apt update && sudo apt upgrade -y

Fail2Ban (optional but recommended):

   sudo apt install fail2ban -y
   sudo systemctl enable fail2ban
   sudo systemctl start fail2ban

Backups:
- Use Infomaniak's backup service
- Regularly backup your application and database
Monitoring:
- Check Infomaniak Manager for resource usage
- Monitor PM2 logs regularly

Infomaniak-Specific Features

VPS Snapshots

Go to Infomaniak Manager → Your VPS
Click Snapshots
Create snapshots before major changes
Restore from snapshots if needed

Resource Monitoring

View CPU, RAM, and disk usage in Infomaniak Manager
Set up alerts for resource thresholds
Upgrade your VPS plan if needed

Support

Infomaniak provides 24/7 support
Access support through the Manager interface
Community forum: community.infomaniak.com

Next Steps

Set up monitoring with tools like UptimeRobot
Configure database backups
Add staging environment
Implement health checks in your workflow
Set up logging with a service like Logtail or Papertrail
Consider using Infomaniak's CDN for static assets

Cost Estimation

VPS Start Plan (3.60 € / month):

Suitable for: 1-3 small Next.js apps
Traffic: Up to moderate traffic levels
Storage: 20 GB (sufficient for code and small databases)

When to upgrade:

High traffic (> 10,000 monthly visitors per app)
Resource-intensive applications
Multiple production applications

Resources

Congratulations! 🎉 Your Next.js app is now deployed on Infomaniak VPS with automatic CI/CD!

How to deploy to Arthera Mainnet

Julien Béranger — Fri, 01 Mar 2024 17:07:04 +0000

Arthera Mainnet is live and it’s time to deploy!

In this tutorial, we’ll learn how to deploy your Solidity contracts to Arthera. We’ll first deploy to the Testnet, and then deploy to Arthera Mainnet.

Deploy to Testnet

Go to the subscription faucet (Testnet), paste your wallet address there: you will get a subscription NFT, it is needed since there’s no AA (native currency of Arthera) in circulation on the network yet. You will deploy your contracts using this address even if the balance is zero, that’s part of the magic of Arthera.
Deploy your Solidity contracts using your favourite tool (Hardhat, Foundry,...) and you can check if everything went well on the explorer (Testnet). Sourcify supports Arthera, so you can verify your contracts both manually and programmatically (you can learn more about this in our docs).

For example, when I deployed a simple NFT contract (view the source code here), the output looked like this:

Optional steps

If you want to offer your users a gas-less experience, you can add these few lines of code in your contract following this tutorial.
Configure the (Testnet) SMP (Subscription Management Platform): https://smp-test.arthera.net/
Add the checkout links to your app or website.

Deploy to Mainnet

Go to the subscription faucet (Mainnet) to get your subscription NFT. For more complex deployments, feel free to reach out to the team.
Deploy your contracts from this address. It should be visible on the explorer (Mainnet)

Optional steps

If you want to offer your users a gas-less experience, you can add these few lines of code in your contract following this tutorial.
Configure the (Mainnet) SMP (Subscription Management Platform): https://smp.arthera.net/
Add the checkout links to your app or website.

Congrats: you're on mainnet! 🎉

The full dev documentation for Arthera is here: https://docs.arthera.net/

And if you need any help or have questions, feel free to contact me directly via Element, Telegram, Twitter, Discord, or LinkedIn.

How to handle your Arthera Lifetime Subscription NFTs

Julien Béranger — Tue, 21 Nov 2023 16:31:59 +0000

Arthera is a Layer 1 EVM-compatible blockchain, improved by DAG-based technology. Testnet is live and Mainnet launches on December 25th 2023.

With a dual model offering both pay-as-you-go and subscription options, Arthera's Lifetime Subscriptions (LTS) provide unparalleled access to our evolving ecosystem. On Arthera you subscribe and forget gas fees - for life.

Get yours here, and/or create your own referral link there.

You can get your limited edition of Arthera Lifetime Subscription (LTS) on seven different networks:

Arbitrum (222)
Avalanche (111)
Base (111)
BNB Chain (333)
Ethererum (444)
Optimism (111)
Polygon (333)

How to add your NFT to your wallet?

The easiest way to add your NFT to your wallet is to:

Go to the explorer of the network/blockchain you selected
Paste your wallet address in the search bar
Find your NFT, in most of explorers there's an "NFT transfers" or "ERC721 Token Txns"
Copy-paste the NFT contract address, and keep the NFT ID in mind
Open MetaMask, and click on the "NFTs" tab
Click on "Import NFT"
Paste the NFT contract address and NFT ID
Click on "confirm"

Voilà! 🎉

You can now transfer your NFT using MetaMask wallet.

If you're using any other wallet, there should be some way to add it to your wallet.

View your NFT

You can also view your NFT in a lot of different NFT marketplaces depending on which network you have claimed it.

What's next?

In a near future, you'll be able to use this NFT to activate your lifetime subscription, forget gas fees, and make up to 30 daily transactions on Arthera at no cost at all. For Life.

Get started with Arthera

Julien Béranger — Tue, 17 Oct 2023 07:49:04 +0000

Arthera is a new L1 in town. It's EVM-compatible, so if you're already familiar with EVM tooling and Solidity, you'll feel right X I'm at home.

We just sealed a partnership with a service called SolidityScan, and it's part of the whole security workflow we're setting up for our own system contracts. But we're also giving access to all applications building on Arthera. To date, there are already more than 80 apps committed to building on Arthera.

I strongly recommend you have a look at our White Paper and mint the NFT that goes with it.

If you're as lazy (efficient) as a good dev should be, or a beginner in Solidity, you can just fork this Hardhat template and build what you want to build from there.

Here are the docs where you'll find answers to all your questions. Whether you're using Hardhat, Foundry, Truffle, Alchemy, Embark, or something else, you can easily add Arthera Testnet to your project:

RPC Endpoint: https://rpc-test.arthera.net
WebSocket Endpoint (Optional): wss://ws-test.arthera.net
Chain ID: 10243

And of course, you're invited to join us in Telegram and get in touch with us!

This is our app store, feel free to submit your app here, we'll be delighted to welcome you.

How to add Arthera subscriptions to your Solidity contracts

Julien Béranger — Wed, 11 Oct 2023 14:12:15 +0000

Forcing users to buy a handful of ETH before they can interact with your contract often makes it unpleasant for them to use your service. It's a classic issue in the crypto space and we all know this kind of friction can make your beloved users leave, never to return again.

Teams like Biconomy, Gelato and others have been working hard to create solutions that remove this friction, mainly by allowing your app to sponsor the transaction fees.

On March 1st, 2023, the Ethereum community collectively decided to natively support what we now call smart wallets or on-chain wallets, referring to account abstraction implementations. Etherspot, Cometh Connect or Safe, and several others are making it easier for devs to integrate with account abstraction to improve the UX for their own app. At Arthera we will hopefully work with all of them. However, as Fabian Vogelsteller mentioned in a recent interview, account abstraction can be pretty complex.

Arthera's approach to fix the classical Web3 UX issue is pretty straight forward. If you want to pay for your gas fees you can: we call it "pay-as-you-go" and it can be useful in some cases. But one of the key features of Arthera is the built-in subscription model where, as an individual, you can purchase a $1 USD monthly subscription and then just forget about gas fees. Moreover, As an app provider, you can present a gas-less service to your users and that's the part I will cover in this tutorial.

Enough talking for today... let’s build!

When you get a subscription plan for your app, you can then whitelist your users so they can use your service even if they have zero AA (the native currency of Arthera) in their wallet.

In addition to that, the SMP (Subscription Management Platform) will allow you to customise certain things, and also create a subscription widget that supports fiat payments. This widget can be easily integrated into your app. To my knowledge this is a world first.

Step 1

Go to Arthera Wallet UI v1 and export the private key to your smart contract development environment (Hardhat, Foundry, etc).

Step 2

Add the ISubscriptionOwner.sol contract interface to your project:

// SPDX-License-Identifier: GPL-3.0
pragma solidity ^0.8.0;

interface ISubscriptionOwner {
    function getSubscriptionOwner() external view returns (address);
}

Note: you can also directly add this contract in your contract file.

Step 3

Add the following imports at the top of your Solidity contract file:

import "./ISubscriptionOwner.sol";
import "@openzeppelin/contracts/utils/introspection/ERC165.sol";

Step 4

Make your contract inherit from both ISubscriptionOwner and ERC165:

contract YourContract is ISubscriptionOwner, ERC165 {
    // ... 
}

Step 5

Add the getSubscriptionOwner() and supportsInterface() functions at the end of your contract:

function getSubscriptionOwner() external view returns (address) {
    return <ADDRESS_OF_THE_SUBSCRIPTION_OWNER>;
}

function supportsInterface(bytes4 interfaceId) public view override(ERC165) returns (bool) {
    return interfaceId == type(ISubscriptionOwner).interfaceId || super.supportsInterface(interfaceId);
}

The address <ADDRESS_OF_THE_SUBSCRIPTION_OWNER> must be the account you created in the beginning of this tutorial (step 1).

The ISubscriptionOwner interface allows Arthera to determine the owner of the subscription, which must be an EOA account (it can't be a contract).

If your contract is ownable, your getSubscriptionOwner() function would eventually look like this:

function getSubscriptionOwner() external view returns (address) {
    return owner();
}

If your contracts inherit from other contracts, you must ensure the order of inheritances is correct; keep in mind that the ERC165 often goes first.

Step 6

Deploy your contract to Arthera Testnet.

Here is the network info:

RPC Endpoint: https://rpc-test.arthera.net
Chain ID: 10243

Step 7

Go to the Arthera SMP (Subscription Management Platform)
In the left menu, click on the "On-Chain" tab
Connect with the subscription owner wallet
Click on "Subscribe" (DApp Plan)
Paste your contract address in the field

You should always use the same account, it's what we call the subscriptionOwner. Get a dApp subscription, then paste the address of your newly deployed contract in the field.

Done! 🎉

At this stage, you're ready to whitelist your users so they can interact with your app without paying any gas fees.

Welcome to Arthera: Enjoy Web3, forget gas fees.

Useful links

Thanks for reading!

Deploy an ERC-20 on Aurora using Hardhat

Julien Béranger — Tue, 08 Nov 2022 16:38:52 +0000

Aurora is an EVM-based network that benefits from the security and scalability of NEAR. Technically, Aurora is a shard of NEAR that supports Solidity. There's nothing as simple as deploying an ERC-20 token on Aurora Testnet.

Aurora Testnet setup

Go to https://aurora.dev/start, in the Aurora Network section, select the testnet tab and click on Add Network: this will add Aurora Testnet as a new network in your MetaMask wallet.

Head to Aurora Testnet faucet and click on the testnet button. Now you can just click on the Connect to Aurora Testnet button, it will turn into a Request 0.001 ETH from faucet button: just click it to get 0.001 ETH. That will be more than enough to deploy your ERC-20 token contract.

If you need more, you can use the Testnet Rainbow Bridge to transfer some Goerli ETH to Aurora Testnet.

Hardhat config

Clone this repository: https://github.com/julienbrg/dune-erc20
Copy the .env.example file
Rename it .env
In MetaMask, export the private key of the wallet holding the Aurora Testnet ETH, copy-paste it after the equal sign (line 3)
In your terminal (in your root directory):

npm i

The ERC-20 contract

This is a very basic ERC-20 token that's using open Zeppelin Solidity contracts library. There's only one function: the mint() function. The visibility is set to public, meaning that anyone can call this function and mint as many units as he/she wants (we're in an 'open bar' mode, so to speak):

// SPDX-License-Identifier: GPL-3.0
pragma solidity ^0.8.4;

import "@openzeppelin/contracts/token/ERC20/ERC20.sol";

contract Dune is ERC20 {
    constructor() ERC20("Dune", "DUNE") {}

    function mint(address to, uint256 amount) public {
        _mint(to, amount);
    }
}

You can test this contract with:

npx hardhat test

Then just deploy it to Aurora Testnet:

npx hardhat run scripts/deploy.ts --network aurora_testnet

You should get something like this:

ERC-20 deployed at 0x51723295B6E50d94D887Bbc70c1AE0ab1Fa3a469 ✅

On Aurorascan, your deployment transaction will look like this:

Congrats, you just deployed a Solidity contract to Aurora Testnet! 🎉

To mint and transfer a handful of DUNE to yourself (or to a friend of yours), you can use this command:

npx hardhat run scripts/transfer.ts --network aurora_testnet

For info, there's even a frontend available if you want to mint some Dune tokens: https://dune-aurora.netlify.app/. It was made using React, Web3Auth and a builder called Plasmic. The Github repo is here (there's a dune branch) if you want to have a look.

Now let's deploy to Mainnet...

Deploy to Aurora Mainnet

We're going to use a tool called Aurora+. Please head to https://aurora.plus, and sign up to get your 50 free tx per months. Once you've done that, you have your personalized RPC endpoint URL that is waiting for you (top-right menu):

You can copy-paste that URL into your .env file (line 1).

Then you want to export your wallet's private key into your .env file as well.

Something is missing in that .env file and it's the Aurorascan API key. You're going to need it to make it easy for everyone to read the source code of your contract, you can use Aurorascan API:

https://aurorascan.dev/myapikey

You can sign up there, click on API-key in the left menu, then click on add to create an API key. Copy-paste it in the .env file.

In the deploy.ts file uncomment the lines 15, 16 and 17, and:

npx hardhat run scripts/deploy.ts --network aurora_mainnet

Congrats! 🎉

Your ERC-20 is deployed to Aurora Mainnet, you paid nothing, the source code is available for everyone to verify what's going on, and people can even trigger the mint function directly from Aurorascan.

And you can also use the transfer.ts script to mint some DUNE:

npx hardhat run scripts/transfer.ts --network aurora_mainnet

Thanks for your read!

Photo by Henrik Heitmann

Feel free to contact me via Element, Telegram, Twitter, Discord, or LinkedIn.

Mint an NFT on zkSync 2.0

Julien Béranger — Sun, 10 Jul 2022 09:41:57 +0000

As we now live in a rollup-centric world, minting an NFT on Ethereum Mainnet (L1) is getting less and less relevant. zkSync 2.0 public testnet went live in February 2022, so let's just give it a try!

Please note that zkSync 2.0 Mainnet is not available yet, but the whole community is waiting for the announcement. When it's out, you'll be ready to deploy your NFT contract.

We'll work with this Github repository, you can go ahead and clone or fork it:

https://github.com/julienbrg/zksync-minter

I mainly used zkSync 2.0 quickstart.

Prerequisites

Please make sure you have the two following tools in place:

Yarn
Docker

Add your own keys

Rename the .env.example to .env. To run the app, you need these three keys to be valid.

Web3 Storage

As you might know, Web3 Storage uses IPFS and Filecoin. We'll use that to store the metadata of our NFT in a rather persistent way.

Infura

You can signup and get a project ID directly on Infura's website: https://infura.io/

Wallet private key

From your ArgentX browser wallet, you can export one of your accounts' private key. Make sure you have a handful of Goerli ETH on this wallet.

Now you can

yarn

Edit the NFT smart contract

In case if your new, an NFT is just a unique digital object. Wether it's a gaming asset, a ticket to a party or an artwork, it most often can be transferred, that's the main feature of an NFT.

I used the Contracts Wizard provided by the all mighty OpenZeppelin team.

It's a very basic ERC-721 contract. In the constructor, you attach the NFT metadata, mint the ID 1, transfer it to yourself and then revoke the ownership of the contract so that absolutely nobody can mint another NFT with this contract (including yourself).

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.4;

import "@openzeppelin/contracts/token/ERC721/ERC721.sol";
import "@openzeppelin/contracts/token/ERC721/extensions/ERC721URIStorage.sol";
import "@openzeppelin/contracts/token/ERC721/extensions/ERC721Burnable.sol";
import "@openzeppelin/contracts/access/Ownable.sol";

contract Thistle is ERC721, ERC721URIStorage, ERC721Burnable, Ownable {

    constructor(string memory uri) ERC721("Thistle", "THISTLE") {
        safeMint(msg.sender, 1, uri);
        renounceOwnership();
    }

    function _baseURI() internal pure override returns (string memory) {
        return "https://ipfs.io/ipfs/";
    }

    function safeMint(
        address to,
        uint256 tokenId,
        string memory uri
    ) public onlyOwner {
        _safeMint(to, tokenId);
        _setTokenURI(tokenId, uri);
    }

    function _burn(uint256 tokenId)
        internal
        override(ERC721, ERC721URIStorage)
    {
        super._burn(tokenId);
    }

    function tokenURI(uint256 tokenId)
        public
        view
        override(ERC721, ERC721URIStorage)
        returns (string memory)
    {
        return super.tokenURI(tokenId);
    }
}

You can change the name of the contract (Thistle), and also the name and symbol of the NFT in ERC721("Thistle", "THISTLE").

Once you've done that, your contract is ready.

You can:

yarn hardhat compile

Edit the NFT metadata

In the nft directory, open the metadata.json file and edit this file exactly like you want. You can use Web3.Storage to store an image and paste the url as the value of image.

Deploy

yarn hardhat deploy-zksync

You should get something like this:

Now you can copy the address of your contract and paste in the search bar of the zkSync 2.0 explorer. Here's my deployment transaction:

https://zksync2-testnet.zkscan.io/tx/0x567037335a70bb01c02bb5f5f6ee2a777f37fc3a3b0c13bae62165e1dbc24c92/token-transfers

You have deployed your NFT contract to zkSync 2.0 testnet and minted 1 NFT! 🎉

View this NFT on Āto

You now hold this NFT in your wallet. The tx was confirmed within 3 seconds. If we were on Mainnet it would have costed less than 0.02 USD equivalent.

When the time's right, you'll be able to:

move your NFT to Ethereum Mainnet (L1)
move it to another L2
build an interface to sell it using the zkSync development toolbox
add a personalized IP license using Āto
store it safely using Argent

If you have any question, feel free to call me or file an issue.

Thanks for reading!

Photo by Jay Mantri

DEV Community: Julien Béranger

Publish encrypted, shareable docs from your terminal (or Claude Code) with Fileverse

Prerequisites

Step 1 — Fileverse signup

Step 2 — Get your API key

Step 3 — Install and run the local API server

Troubleshooting: ERR_MODULE_NOT_FOUND: Cannot find package 'y-protocols'

Step 4 — Install share

What share does behind the scenes

Step 5 — Verify setup

Step 6 — Updating a published doc

Step 7 — Claude Code /share command

Make it your own

Recap

Getting Started with Genji: A Web3 App Starter with Passkey Authentication

What's in it?

Privacy-Friendly Architecture

Installation and Setup

Step 1: Create Your Repository

Step 2: Customize the Template

Step 3: Install Dependencies

Step 4: Start the Development Server

Step 5: Configure Security Level

Understanding Passkey Authentication

Best Practices

Support and Resources

Conclusion

Deploy a Next.js app to an Infomaniak Ubuntu VPS

Prerequisites

0. Order Your Infomaniak VPS

0.1 Choose Your Plan

0.2 VPS Configuration

0.3 Complete Your Order

0.4 Access Infomaniak Manager

1. Infomaniak Firewall Configuration

1.1 Access Firewall Settings

1.2 Required Firewall Rules

1.3 Verify Firewall Status

2. VS Code SSH Configuration

2.1 Install Remote SSH Extension

2.2 Generate SSH Key (if you don't have one)

2.3 Copy SSH Key to VPS

2.4 Configure VS Code SSH

2.5 Connect to VPS from VS Code

2.6 VS Code Tips for Remote Development

3. Fork the Repository

4. VPS Initial Setup

4.1 Connect to your VPS

4.2 Update System

4.3 Install Node.js via NVM

4.4 Install pnpm

4.5 Install PM2 (Process Manager)

4.6 Clone your repository on the VPS

4.7 Install dependencies and build

4.8 Start the app with PM2

5. Domain and DNS Configuration

5.1 Configure DNS

7.2 Verify DNS

6. Nginx Configuration

6.1 Install Nginx

6.2 Create Nginx configuration

6.3 Enable the site

7. SSL Certificate Setup

7.1 Install Certbot

7.2 Obtain SSL certificate

7.3 Verify SSL certificate

8. UFW Firewall Configuration (Additional Layer)

9. GitHub Actions CI/CD Setup

9.1 Create SSH key for GitHub Actions

9.2 Copy the private key

9.3 Create GitHub workflow file

9.4 Add GitHub Secrets

9.5 Commit and push

10. Test Your Deployment

Useful Commands

PM2 Management

Nginx Management

SSL Certificate Management

Checking Open Ports

Firewall Management

Troubleshooting: `ERR_MODULE_NOT_FOUND: Cannot find package 'y-protocols'`

Step 4 — Install `share`

What `share` does behind the scenes

Step 7 — Claude Code `/share` command