Practical Technology Guides: Passkeys, Docker Compose Watch, Ollama, and GitHub Copilot Cloud Agent

Practical Technology Guides Today: Passkeys, Docker Compose Watch, Ollama, and GitHub Copilot Cloud Agent

Image citation: “Programming.jpg”, Wikimedia Commons. Image source: https://commons.wikimedia.org/wiki/File:Programming.jpg. Format used: JPG, not SVG.

This guide focuses on four practical technology areas that are immediately useful for developers and technical teams: passkeys for safer sign-in, Docker Compose Watch for faster local development loops, Ollama for running AI models locally, and GitHub Copilot Cloud Agent for branch-and-pull-request based coding delegation. The emphasis is on implementation steps, deployment checklists, and authoritative references.

Quick summary

Passkeys are useful when you want safer sign-in and less dependence on passwords. Docker Compose Watch is useful when you develop inside containers and want local file changes to update services without constant manual rebuilds. Ollama is useful when you want to prototype local AI workflows or call a model through a local API. GitHub Copilot Cloud Agent is useful when you want to delegate small issues, refactors, documentation updates, or test coverage improvements through a branch and pull request workflow.

Primary references include Microsoft Learn for Windows passkeys, Google Developers for passkeys in web apps, Docker Docs for Compose Watch, Ollama Docs for the API, and GitHub Docs for Copilot Cloud Agent.

---

1. How to start with passkeys and reduce password dependence

Image citation: “SecureID token new.JPG”, Wikimedia Commons. Image source: https://commons.wikimedia.org/wiki/File:SecureID_token_new.JPG. Format used: JPG, not SVG.

What problem do passkeys solve?

Passkeys are a sign-in method based on public/private key cryptography rather than shared passwords. The private key stays on the user’s device or credential manager, while the service stores the public key. During sign-in, the device proves possession of the private key by signing a challenge instead of sending a password through a form. Microsoft Learn explains that passkeys can use device unlock mechanisms such as Windows Hello, biometrics, or a PIN, and are designed to reduce risks such as password guessing, password reuse, and phishing. Source: https://learn.microsoft.com/windows/security/identity-protection/passkeys/.

Google Developers describes passkeys as a way for users to sign in to a website or app using the device’s screen lock mechanism, such as a fingerprint, face unlock, or device PIN. For web implementation, a passkey must be created, linked to a user account, and have its public key stored on the server before it can be used for sign-in. Source: https://developers.google.com/codelabs/passkey-form-autofill.

When should you implement passkeys?

Prioritize passkeys if your product has frequent password resets, sensitive account data, phishing exposure, or a user base that signs in often from personal phones and laptops. Passkeys are especially relevant for SaaS applications, customer accounts, internal admin portals, and high-value user profiles.

Do not treat passkeys as a one-step replacement for your entire authentication policy. For a production system, introduce them gradually: let users add a passkey from account security settings, keep recovery options during the transition, log passkey creation and deletion events, and prepare a support workflow for lost devices.

Website implementation checklist

First, verify browser and platform support for WebAuthn/passkeys in your target user base. A web app needs a passkey registration flow, a passkey sign-in flow, user-friendly device names, and a screen where users can revoke old passkeys.

On the backend, store the public key, credential ID, user mapping, and any authenticator metadata required by your WebAuthn library. Do not design your own cryptographic protocol unless you have the required security expertise. Use a mature WebAuthn library for your backend language.

For user experience, place “Sign in with a passkey” on both the login screen and the account security page. Explain the feature plainly: the user does not send a password to the website; they confirm sign-in with their device. If your audience is not technical, state that a passkey can live on a phone, laptop, browser, or password manager.

Common mistakes

The most common mistake is hiding passkeys deep inside settings, so users never enable them. The second is failing to provide an account recovery path for users who lose a device. The third is describing a passkey as “a new password.” A clearer message is: a passkey is a passwordless sign-in method based on cryptographic keys and device unlock.

---

2. How to use Docker Compose Watch for faster local development

Image citation: “Docker (container engine) logo.png”, Wikimedia Commons. Image source: https://commons.wikimedia.org/wiki/File:Docker_(container_engine)_logo.png. Format used: PNG, not SVG.

What is Docker Compose Watch?

Docker Compose lets you define services, networks, and volumes in a YAML file, then start the whole application stack with a single command. Source: https://docs.docker.com/compose/.

Compose Watch tracks local file changes during development. Docker Docs states that Compose Watch is designed for services built from local source code using the build attribute. It does not track changes for services that only use pre-built images through the image attribute. Source: https://docs.docker.com/compose/how-tos/file-watch/.

When should you use Compose Watch?

Use Compose Watch when your frontend, backend, or worker runs inside a container and you want host-side code changes to update the container quickly. In JavaScript or TypeScript projects, it is useful when you want to sync src while avoiding node_modules, which can be large, slow, and platform-specific.

Docker Docs describes Watch as a companion to bind mounts, not a total replacement. Bind mounts remain useful when you need to share a whole host directory with a container. Watch is better when you want more precise rules: which files to sync, which changes should rebuild the image, and which paths should be ignored. Source: https://docs.docker.com/compose/how-tos/file-watch/.

Basic configuration example

services:
  web:
    build: .
    command: npm run dev
    ports:
      - "3000:3000"
    develop:
      watch:
        - action: sync
          path: ./src
          target: /app/src
        - action: rebuild
          path: package.json
        - action: rebuild
          path: package-lock.json

This configuration syncs changes in src into the container and rebuilds the image when dependency files change. For Node.js projects, avoid syncing node_modules from the host into the container because native packages can differ between host and container environments.

Recommended command

docker compose watch

Some workflows can also use:

docker compose up --watch

Before applying Watch to a large project, test it on one service first. Confirm that the container can write to the target path. Docker Docs notes that Watch relies on common executables such as stat, mkdir, and rmdir, and that the container user must have write permission for the target path. Source: https://docs.docker.com/compose/how-tos/file-watch/.

Optimization checklist

Do not enable Watch for every service by default. Enable it only for services under active development, usually the frontend or API. Ignore generated folders, caches, build output, and large dependency directories where appropriate. Separate sync and rebuild rules: source code usually syncs, dependency manifests usually rebuild.

---

3. How to run local AI with Ollama and call it through an API

Image citation: “Artificial Intelligence & AI & Machine Learning - 30212411048.jpg”, Wikimedia Commons. Image source: https://commons.wikimedia.org/wiki/File:Artificial_Intelligence_%26_AI_%26_Machine_Learning_-_30212411048.jpg. Format used: JPG, not SVG.

Why try local AI?

Local AI is useful when you want to experiment with language models on your own machine, keep development data under tighter control, or build prototypes that do not depend entirely on cloud APIs. Ollama lets you run models locally and call them through an API. According to Ollama Docs, after installation the API is served by default at http://localhost:11434/api, and available endpoints include generate, chat, embed, tags, pull, and delete. Source: https://docs.ollama.com/api/introduction.

Install and test quickly

After installing Ollama for your operating system, check the version:

ollama --version

Pull a model that fits your machine:

ollama pull gemma3

Run the model interactively:

ollama run gemma3

Call the API with curl:

curl http://localhost:11434/api/generate -d '{
  "model": "gemma3",
  "prompt": "Write a basic security checklist for a small website."
}'

Ollama Docs provides a curl example for the generate endpoint and notes that official libraries are available for Python and JavaScript. Source: https://docs.ollama.com/api/introduction.

Application integration pattern

For an internal app, create a backend service that calls the Ollama API rather than calling it directly from the frontend. This gives you a place to control prompts, filter sensitive data, add logging, and enforce access rules. Do not expose a local Ollama endpoint to the public Internet unless you have authentication, rate limiting, and access control in place.

Minimal Node.js example:

const response = await fetch('http://localhost:11434/api/generate', {
  method: 'POST',
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify({
    model: 'gemma3',
    prompt: 'Summarize the following text into five key points: ...',
    stream: false
  })
});

const data = await response.json();
console.log(data.response);

Data safety checklist

Do not put secrets, private keys, access tokens, or sensitive customer data into experimental prompts. On shared company machines, define who can access the model, what is logged, and which model is approved. If you move from prototype to production, evaluate model quality, latency, hardware cost, monitoring, failure modes, and rollback options.

---

4. How to delegate work to GitHub Copilot Cloud Agent through pull requests

Image citation: “Colorful code (Unsplash).jpg”, Wikimedia Commons. Image source: https://commons.wikimedia.org/wiki/File:Colorful_code_(Unsplash).jpg. Format used: JPG, not SVG.

How is Copilot Cloud Agent different from AI chat in an IDE?

GitHub Docs states that Copilot Cloud Agent can research a repository, create an implementation plan, make code changes on a branch, let you review the diff, iterate, and create a pull request when ready. GitHub also describes the agent as working inside its own ephemeral development environment powered by GitHub Actions, where it can explore code, make changes, and run tests and linters. Source: https://docs.github.com/copilot/concepts/agents/cloud-agent/about-cloud-agent.

The key difference is that Copilot Cloud Agent works asynchronously on GitHub, while IDE agent mode usually edits files directly in a developer’s local environment. Cloud Agent is therefore better suited for clear issues, small-to-medium tasks, and changes that should be reviewed through a branch and pull request.

What kind of tasks should you delegate?

Good tasks include clearly scoped bug fixes, unit test additions, README updates, small refactors, logging improvements, lint fixes, better error messages, or narrow dependency upgrades. Avoid vague requests such as “optimize the whole system” unless you provide context, acceptance criteria, and boundaries.

Prompt template for a coding task

You are working in this repository. Read the project structure before changing code.

Goal:
- Fix [specific bug description].
- Preserve existing behavior outside the bug scope.
- Add or update tests if the project has a relevant test framework.

Constraints:
- Do not change the public API unless necessary.
- Do not add a new dependency if the existing stack can solve the issue.
- After making changes, run relevant lint/tests and report the result.

Acceptance criteria:
- The bug is reproduced, or you clearly explain why it could not be reproduced.
- The diff is small and reviewable.
- The pull request description explains the change.

Review checklist for AI-created pull requests

Do not merge only because CI is green. Read the diff, verify business logic, check security implications, inspect whether tests actually cover the bug, and confirm that the change stays within scope. If the PR touches authentication, billing, permissions, or user data, review it as carefully as code from a new developer.

GitHub Docs lists Cloud Agent use cases including fixing bugs, implementing incremental features, improving test coverage, updating documentation, addressing technical debt, and resolving merge conflicts. Source: https://docs.github.com/copilot/concepts/agents/cloud-agent/about-cloud-agent.

---

Fast selection table

SEO and GEO FAQ

Do passkeys replace passwords immediately?

Not for most existing production systems. A safer rollout is to add passkeys as an optional sign-in method, keep recovery channels, and measure adoption before requiring migration.

Does Docker Compose Watch replace bind mounts?

Not completely. Docker Docs describes Watch as a companion for containerized development, especially when precise sync and rebuild rules are better than mounting a whole directory.

Is Ollama suitable for production?

It can be suitable for some controlled internal systems, but you must evaluate security, performance, monitoring, GPU/CPU resources, model updates, and access control. Do not expose a local Ollama API to the Internet without authentication and safeguards.

Should AI-generated pull requests be merged without review?

No. A pull request created by an AI agent still requires normal engineering review. Check the diff, tests, scope, security, and product impact before merging.

References

1. Microsoft Learn — Support for passkeys in Windows: https://learn.microsoft.com/windows/security/identity-protection/passkeys/
2. Google Developers — Implement passkeys with form autofill in a web app: https://developers.google.com/codelabs/passkey-form-autofill
3. Docker Docs — Docker Compose: https://docs.docker.com/compose/
4. Docker Docs — Use Compose Watch: https://docs.docker.com/compose/how-tos/file-watch/
5. Ollama Docs — API Introduction: https://docs.ollama.com/api/introduction
6. GitHub Docs — About GitHub Copilot Cloud Agent: https://docs.github.com/copilot/concepts/agents/cloud-agent/about-cloud-agent
7. Wikimedia Commons — Programming.jpg: https://commons.wikimedia.org/wiki/File:Programming.jpg
8. Wikimedia Commons — SecureID token new.JPG: https://commons.wikimedia.org/wiki/File:SecureID_token_new.JPG
9. Wikimedia Commons — Docker logo PNG: https://commons.wikimedia.org/wiki/File:Docker_(container_engine)_logo.png
10. Wikimedia Commons — Artificial Intelligence & AI & Machine Learning: https://commons.wikimedia.org/wiki/File:Artificial_Intelligence_%26_AI_%26_Machine_Learning_-_30212411048.jpg
11. Wikimedia Commons — Colorful code (Unsplash).jpg: https://commons.wikimedia.org/wiki/File:Colorful_code_(Unsplash).jpg