This should prevent us from generating different diffs and adding noise
to our PRs. Patience seems like a good one; it generated a diff that I
felt was easier to read in the case of the yarn.lock optionator section.
I've been coding from my iPad to Raspberry Pi going on several months. I feel a pro at it and far prefer it over a cloud service for it has far less lag being local hosted.
`file` doesn't seem to work without a specific git reference, but adding
a reference makes the explorer not follow the tour. Unfortunately
`directory` doesn't show the directory contents so I added the directory
name and "see the explorer" to the comment.
Looks like
```
-r --reuse-window Force to open a file or folder in an already opened window.
-vvv --verbose Enable verbose logging.
--link (beta) Securely bind code-server via Coder Cloud with the passed name. You'll get a URL like
https://myname.coder-cloud.com at which you can easily access your code-server instance.
Authorization is done via GitHub.
```
Based on commits by @JammSpread in #2405Closes#2396
Safari runs code-server horribly. We shouldn't even pretend that it sort
of works.
See the issues tagged browser-safari!
Considered Firefox first but there's too many issues with it as well.
I took our website's SVG favicon and plopped it on a round
white rectangle in Affinity Designer. The I exported it as an SVG and
wrote a script that uses imagemagick to convert to the various sizes and
formats we need.
Closes#2307
Forgot an extra 60 in the check interval and the notification timeout.
Very unfortunate. Check has been allowed every 168 minutes instead of
every week.
Based on the previous commits by @mgmachado but simplified.
I also changed the threshold to error after a single attempt as the
connection has likely been borked and the user should be in the know if
they couldn't reconnect after 5 seconds.
Closes#1791
I disabled code-layering and code-import-patterns as I don't think we
can make them easily pass as we reference all sorts of code from both
browser and node files. At least not worth the headache now to refactor
everything.
Previously anything that wasn't "log" such as "warn" would end up doing
`logger[logger.warn]`. Would have caught this if I hadn't used `any`...
Fixes#2364.
The new fields are from vscodium and make the welcome page
documentation links work correctly.
I also renamed the distribution to "code-server" so that when you're
in a browser, it now says code-server instead of Code OSS.
It's possible that using browser storage makes more sense with settings
sync, so we might want to revisit this once/if we get settings sync
working. As it currently is though, browser storage just causes jank.
The path was also missing a `User` at the end so I added that. This
might affect the Vim extension which would have been writing to the
wrong path previously but I don't believe it should affect anything
else since they would have been writing to browser storage.
- Fixes#2208
- Fixes#2231
- Fixes#2279
- Fixes#2274
The telemetry service depends on this now. I had to move it into
invokeFunction and use accessor.get otherwise getLogger on the service
was undefined.
I also had to move some the extension management service because it
depends on the moved telemetry service. I moved a few other services as
well to better match VS Code (sharedProcessMain.ts).
I swapped some this.services.get with accessor.get since that seems to
be the correct method although for these other services either method
seems to work.
I removed this under the impression the default was to allow it anywhere
but that's not the case. Since the service worker was already registered
in my browser I never got the error during testing.
Also move our memory default to the beginning of NODE_OPTIONS so it can
be overidden. The version of the flag with dashes seems to be the more
correct one now so use that instead of underscores.
Related: #2113.
I think having them combined and relying on if statements was getting
confusing especially if we want to add additional messages with
different payloads (which will soon be the case).
Turns out that while Typescript can't infer the callback return type
from it, Typescript can do the opposite and infer it from the callback
return type.
Unfortunately we can't use node-mocks-http to test a express.Router
that has async routes. See https://github.com/howardabrams/node-mocks-http/issues/225
router will just return undefined if the executing handler is async and
so the test will have no way to wait for it to complete. Thus, we have
to use supertest which starts an actual HTTP server in the background
and uses a HTTP client to send requests.
This is mostly so we don't have to do any wacky patching but it also
makes it so we don't have to keep checking if the request is a web
socket request every time we add middleware.
This way the connection can be initiated by either side. It looks like
sometimes the initial message from the client is lost (it never makes it
into the onControlMessage callback) but I'm still not sure why or if
that is preventable.
Also added a timeout on the server end to clean things up in case the
client never responds.
Now we add a subject alt name, set extendedKeyUsage and use the
correct certificate extension.
The above allow it to be properly trusted by iOS.
See https://support.apple.com/en-us/HT210176
*.cert isn't a real extension for certificates, *.crt is correct
for it to be recognized by e.g. keychain or when importing as a profile
into iOS.
Updates #1566
I've been able to successfully connect from my iPad Pro now to my
code-server instance with a self signed certificate! Next commit
will be docs.
If do not update the UID within the passwd database to match whatever
uid the container is being ran as, then sudo will not work when renaming
the user to match $DOCKER_USER as it will complain about the current
user being non-existent.
Removing them just for peace of mind even though they seem to get
filtered out later. This line is meant to only add remote extensions
that aren't capable of running in the browser. If they are
browser-capable they don't need to run in our shimmed Node environment.
This makes the fetch work independently of the worker's origin which is
no longer the same as the main thread (the main problem is the inability
to send cookies without setting SameSite to None).
This matches with the html in the VS Code repo and also fixes a problem
with the worker which loads HTML using data: and then can't load any
scripts because 'self' doesn't work.
- The .js build files are no longer committed so they're gone.
- ParsedArgs and EnvironmentService are now NativeParsedArgs and
NativeEnvironmentService.
- Interface for environment service was moved.
- getPathFromAmdModule was deprecated.
Otherwise it outputs when trying to open a file in an existing instance
externally. Externally there isn't an environment variable to branch on
to skip this line so instead output it with the other info lines in the
child process.
- Immediately create ipcMain so it doesn't have to be a function which I
think feels cleaner.
- Move exit handling to a separate function to compensate (otherwise
the VS Code CLI for example won't be able to exit on its own).
- New isChild prop that is clearer than checking for parentPid (IMO).
- Skip all the checks that aren't necessary for the child process (like
--help, --version, etc).
- Since we check if we're the child in entry go ahead and move the
wrap code into entry as well since that's basically what it does.
- Use a single catch at the end of the entry.
- Split out the VS Code CLI and existing instance code into separate
functions.
We only want to use an old version for glibc which the centos:7
image takes care of.
The old version of git used in debian:8 was causing problems
with the uid/gid passthrough with no user in passwd.
We do not try renaming $HOME anymore as there is no good way
to do it.
We also only try to convert if the user hasn't been changed.
Finally I added usage to the docker docs in install.md
Closes#2056
VS Code has a short delay before writing storage (probably to queue up
rapid changes). In the web version of VS Code this happens on the client
which means if the page is reloaded before the delay expires the write
never happens.
Storage updates are already promises so this simply returns the promise
returned by the delayer so it won't resolve until the write actually
happens.
Fixes#2021.
Add initial support for opening files / folders in running code-server instance.
Current limitations:
- unable to open a file in a new window, only folders
- unable to use addMode feature
- others...
We need the handler to be recognized as a PWA but we can just let the
original offline browser message show instead of our own message.
See #1925 and #1979.
tsc doesn't check if the output exists when incremental is true.
i.e if I delete the out directory, but keep the tsbuildinfo and
try to rebuild, nothing happens cause it thinks everything is
up to date I guess...
With this change, yarn clean will now remove the tsbuildinfo correctly
so things work as expected.
Otherwise the build keeps failing for me as tsc won't compile anymore.
Not sure why things work on CI/for asher but I don't think this will
cause any additional issues.
It can still be used to check for updates but will not apply them.
For now also remove the update check loop in VS Code since it's
currently unused (update check is hardcoded off right now) and won't
work anyway since it also applies the update which now won't work. In
the future we should integrate the check into the browser update
service.
- Instead we now use CentOS 7 for the static build to guarantee
that we only depend on libc v2.17
- For macOS we now pull in a static node binary and bundle that instead.
This release fixes bugs introduced with the release of v3.3.0
- We've reverted to VS Code 1.45.1 due to bugs in 1.46 #1667
- Accessing code-server from a web browser on Windows has been fixed#1642
- Search in project has been fixed#1665
- The glibc requirement on static releases has been lowered to v2.19 #1656
Pass the user data dir to the browser environment service then derive
all the paths we can based off that path like the global storage path
which the vim extension uses to store history (otherwise it gets stored
in the working directory from when code-server was spawned).
Arguably the better solution is to use the userdata scheme but that
won't work because the vim extension ignores the VS Code API.
Fixes#1551.
See #1532 for more context.
- Errored JSON requests will get back the error in JSON instead of using
the status text. This seems better to me because it seems more correct
to utilize the response body over hijacking the status text. The
caller is expecting JSON anyway. Worst of all I never actually set the
status text like I thought I did so it wasn't working to begin with.
- Allow the update error to propagate for JSON update requests. It was
caught to show the error inline instead of an error page when using
the update page but for JSON requests it meant there was no error and
no error code so it looked like it succeeded.
- Make errors for failed requests to GitHub less incomprehensible.
Previously they would just be the code which is no context at all.
The raw value is now passed back to VS Code so it can do the parsing
with its own URI class rather than trying to parse using Node's url
module first since that has no guarantee of working the same way. It
also lets us keep the vscode-remote bit internal to VS Code.
Removed the logic that keeps trying paths until it finds a valid one
because it seems confusing to open a path and silently get some other
path instead of an error for the one you tried to open. Now it'll just
use exactly what you specified or fail trying.
Fixes#1488. The problem here was that url.parse was encoding the spaces
then the validation failed looking for a literal %20.
- Add type to HTTP options.
- Fix certificate message always saying it was generated.
- Dedent output not directly related to the HTTP server.
- Remove unnecessary comma.
In Google cloud shell the host header is 127.0.0.1:8080 instead of the
actual URL. This is what we write out to the HTML so VS Code can pick it
up. However cloud shell rewrites this string when found in the HTML
before serving it so it becomes https://8080-[...].appspot.com,
resulting in an extra unexpected https:// in the
URI (vscode-remote://https://8080[...]). The resulting malformed URI
causes the extension host to exit.
- Fixes#1471
- Fixes#1468
- Fixes#1440 (most likely).
This will make it work regardless of what the current URL happens to be.
Also move the telemetry setting into the options since we might as well
make use of it seeing as how we have to parse it for the base path
anyway.
By design the disable-telemetry flag does not affect extension
telemetry, only the setting does, so disabling the setting when the flag
is set should cause extensions to also stop sending telemetry.
Fixes#1116.
It still won't work behind a base path, but if you're using a reverse
proxy you can just redirect to HTTPS yourself. And should probably
handle TLS termination there too.
For sockets I just needed to add back the proxy call.
I temporarily removed this during the refactor so it needed to be added
back. This time I bundled it with the nbin loader code since it's all
related (will also make it easier to remove).
- Add VS Code icon
- Trim dashboard to just display dedicated VS Code section
- Version was getting unset during build
- Add back nbin shim which I temporarily took out earlier
- Update tests for log level env var changes
Might fix#1181, although not for the reasons I initially
thought (because the URLs are resolved from the manifest path, not the
path of the current page). This should ensure that the URLs used by the
manifest are always correct regardless of the manifest's path.
When using a query parameter without a scheme, the scheme defaults to
`file`. This results in the files in the explorer being technically
different from the file picker files because they are file:// instead of
vscode-remote://, causing the same file to open twice and causing
numerous issues.
Normally the file explorer wouldn't even load at all in this case but we
provide a file service for file:// URLs as a failsafe for certain files
that wouldn't load correctly in the past. These files load fine now
using the vscode-remote scheme, so I'm also removing that service.
Related: #1351.
Fixes#1294.
https://github.com/cdr/code-server/issues/1188
Fixes issue with permissions mounting in directories in the container. Folders are generated by root causing issues when the container user "coder" wants to create sub-folders. This fix solves it, at least on Crostini (ChromeOS)
Fixes issues with unexpected characters breaking things when setting the
cookie (like semicolons).
This change as-is does not affect the security of code-server
itself (we've just replaced the static password with a static hash) but
if we were to add a salt in the future it would let us invalidate keys
by rehashing with a new salt which could be handy.
If you visit /login/ instead of /login the cookie will be set at /login
instead of / which means the cookie can't be read at the root. It will
redirect to the login page which *can* read the cookie at /login and
redirect back resulting in an infinite loop.
The previous solution relied on setting the cookie at / (any invalid
value works) which then overrode the login page cookie since
parseCookies only kept a single value. So the login page would see the
same cookie the root was seeing and not redirect back. However, that
behavior depends on the cookies being in the right order which I'm not
sure is guaranteed.
This new method tests all available cookies and always sets the cookie
so the root path will be able to read it in case the login page is
seeing a cookie the root can't.
It also goes a step further and explicitly sets the path on the cookie
which fixes the case where there is a permanent misconfiguration
redirecting /login to /login/. Otherwise the cookie would continually be
set on /login only and you'd have another loop. It also means you only
need to delete one cookie to log out.
Lastly add some properties to make the cookies a bit more secure.
It doesn't show in the explorer anymore so there's no point. Also remove
the local scheme transform which is no longer required with the latest
client-side extension implementation.
Instead of doing a separate redundant build. The main problem was that
the files weren't being cached. There is probably a better way of
solving this but this seems to be the simplest for now.
This matches how the rest of the build is organized but also hopefully
solves an issue where the VS Code directory is empty because we try to
cache it directly and Travis might be creating it.
Also too the opportunity to rewrite the build script since there was a
change in the build steps (mainly how the product JSON is inserted) and
to get the build changes out of the patch. It also no longer relies on
external caching (we'll want to do this within CI instead).
- Copy old icon back into repository
- Update path to icon from manifest file
- Add link metadata tag for iOS PWA icon to workbench.html
- Add link metadata tag for iOS PWA icon to login page
* [README] add Requirements section
This is based user feedback and testing. This may expand if need be
Signed-off-by: Ayane Satomi <chinodesuuu@gmail.com>
* [README] raised the bar a bit more
Apparently we were targeting GLIBC 2.17
Signed-off-by: Ayane Satomi <chinodesuuu@gmail.com>
- Don't error if trying to tag and the tag already exists.
- Add the build arguments to the Docker build.
- Set an environment variable for the Docker build rather than using
- the username because the username always exists (on master anyway).
* made spacing for travis yaml consistent in file
* cleaned up .travis.yml and moved some code into a script
* checking if i can get travis to build this
* travis
* fixed an if statement
* fixed travis.yml file
* replaced my name with codercom
There's no way to actually know if those clients have gone away, so it
seems it might be better to base it on whether the user has connected
again with new clients to determine if the old clients are now invalid.
It gets the web URL for the file yet uses the file service to load it,
so having a sub-path causes it not to be found on disk (the sub-path
obviously only means anything for the web server and isn't on disk).
This removes the potential for a bad build because the native Node
modules currently can only be built on the target system, so specifying
a target for something other than the system your are building on will
not work.
- Implement the localization service.
- Use the proper build process which generates the require JSON files.
- Implement getting the locale and language configuration.
- Don't use "any" for the API type.
- Remove everything from the Coder API that can eventually be done
through the VS Code API.
- Move the event emission to our own client to minimize patching.
This means that you have to turn on features now instead of disabling
them like auth and https.
In addition:
- Allow multiple options for auth (only password for now).
- Combine the install docs since they had many commonalities and
- generally simplified them (hopefully not too much).
- Move all example configs into docs/examples.
When `isAuthed()` is called and the password cookie is not what we
expected, the failed login attempt is logged with the provided password,
remote address and user agent.
To allow for logging failed attempts with a reverse proxy, the
`--trust-proxy` argument has been added to trust the `X-Forwarded-For`
header. This implementation of an `X-Forwarded-For` parser uses the last
value in the list, therefore only trusting the nearest proxy.
I run code-server behind an authenticating Kubernetes Ingress which sets a cookie after a successful login is performed. Since this cookie is not set when fetching the manifest, the fetch fails and gets redirected to the authentication page, breaking code-server completely.
See https://developer.mozilla.org/en-US/docs/Web/HTML/Element/link
This is to match how the other binaries are built. Also made some
changes to make the Docker containers clean up for when you are running
this locally.
Since there is no other way to enable hidden files, it seems better to
enable it by default otherwise there are some folders/files you simply
can never open from the dialog.
* Set NODE_ENV and VERSION when building
Should fix the version flag not reporting correctly as well as enable
the service worker and prevent the 404 hmr requests again.
* Log env vars
To help make sure it's built correctly when looking at the Travis logs.
Since this will be a path in the binary that we don't want to create on
the user's system. I also removed the option to override it; it doesn't
seem like a great idea since you'd always want those builtin extensions.
This way we also don't have to check if the option was passed and only
create it if that was the case.
This isn't a real error event; we artificially emit it just in case
something waiting to start is listening to the error event in order to
clean up and/or restart.
* Allow setting paths for builtin exts and extra dirs
The extra directories aren't used yet, just available from the
environment service and to the shared process.
* Utilize extra builtin extensions path
* Utilize extra extensions directory
* Fix cached mtimes for extra extension dirs
* Simplify extension cache equality check
* Implement write/read buffers in electron fill
This makes cutting and copy files from the file tree work.
* Implement fs.createReadStream
This is used by the file tree to copy files.
* Allow passing proxies back from client to server
This makes things like piping streams possible.
* Synchronously bind to proxy events
This eliminates any chance whatsoever of missing events due to binding
too late.
* Make it possible to bind some events on demand
* Add some protocol documentation
* Let people know when telemetry is disabled, change url to https if secure connection
* Remove --no-auth as a http candidate
* Rename variable, change let to const
* Make all assets unique
All CSS and JavaScript files have unique names now. I also moved the
login to the /login path in order to ensure the HTML for each page is
also unique.
* Explicitly include assets to cache
* Added serviceworker and manifest.json
* added deps in package.json
* fixed image link
* actually fixed images i think
* added assets to individual module folders
* added caching
* Serviceworker now properly loads
* Changed single to double quotes
* Update lock
* moved the service worker back into prod only
* removed sw from general
* changed background color of splash screen
* added logo to server
* centralized logo into single assets folder
* Update Node to 10.15.1
* Remove string replace that was used for oclif
* Update nbin
* Package node-pty and spdlog with nbin
* Label stderr/stdout from shared process
* Remove fork override
* Prevent "already disposed" errors when trying to kill disposed proxies
* Include spdlog dependencies
* Shim /node_modules
* Add node_modules to Docker ignore
It keeps using my already-built .node files which results in a
mismatching GLIBC version error.
* Update nbin
* Allow use of the enter key for password input for code-server
* Remove function, make html form
* Remove function and create html form
* Handle form submit action
* Remove button listener
* Check if form exists
- "Open folder" now says "open folder" instead of "open file"
- "Open folder" won't allow you to open files
- "Open file" won't allow you to open directories
Fixes#249.
* Update VS Code to 1.33.0
* Fix slow file tree
* Fix WindowsService fill
* Provide `off` on event listeners
* Fix webview
* Fix double title bar and missing preferences on Mac
* Bump VS Code version in Travis config
* Fix black dialog text (again)
* Fix shared process not starting
- Adds dumb-init so closes#403, closes#361, closes#383
- User mode docker so closes#192, closes#65
- Uses latest docker ubuntu instead of 18.10 which is the rolling tag so closes#404
Thanks to @RichardMcSorley and @sr229
* Add clear error message if port is in use
* Add bold function for text/numbers
* remove unused dependency:
* remove unused line break
* Change logger message
* Use NodeJS.ErrnoException type
* Add back check for error code
* Adjust linux distro to ubuntu 14.04
* Cache lib directory for speedy builds
* Fix path linking for default extensions
* Update reset
* Reset to head
* Improve caching
* Still run yarn in CI
* Update yarn before install
* Increase cache timeout
* Install vscode from vstar
* Undo data-dir changes to CLI, add back clean, remove unused CI func
* Remove additional flags added
* Remove unused dependency
* Reset vscode install dir so patching always works
* Convert fully to protobuf (was partially JSON)
* Handle all floating promises
* Remove stringified proto from trace logging
It wasn't proving to be very useful.
Registering returns an instance that lets you retry and recover without
needing to keep passing the name everywhere.
Also refactored the shared process a little to make better use of the
retry and downgraded stderr messages to warnings because they aren't
critical.
tslint-language-service is the deprecated version which we don't
actually even have listed in the package.json. typescript-tslint-plugin
is the new version.
* Make proxies decide how to handle disconnects
* Connect to a new terminal instance on disconnect
* Use our retry for the watcher
* Specify method when proxy doesn't exist
* Don't error when closing/killing disconnected proxy
* Specify proxy ID when a method doesn't exist
* Use our retry for the searcher
Also dispose some things for the watcher because it doesn't seem that
was done properly.
The searcher also now starts immediately so there won't be lag when you
perform your first search.
* Use our retry for the extension host
* Emit error in parent proxy class
Reduces duplicate code. Not all items are "supposed" to have an error
event according to the original implementation we are filling, but there
is no reason why we can't emit our own events (and are already doing so
for the "disconnected" event anyway).
* Reconnect spdlog
* Add error message when shared process disconnects
* Pass method resolve to parse
* Don't pass method to getProxy
It doesn't tell you anything that trace logging wouldn't and has
no relation to what the function actually does.
* Fix infinite recursion when disposing protocol client in tests
* Add information about release notifications/gif
* Remove unecessary space
* Add smaller gif
* Add even smaller gif
* Trim time in new gif
* Cropped a tad more
* Fix weird aligning
* Set low CPU priority on watcher
Fixes#247.
* Batch stat and readdir calls
* Fix fs.exists
callbackify seems to always adds an error as the first argument. Opted
to just use the promise for this one.
* Batch lstat
* Add maximum time for flushing batches
* Replace evaluations with proxies and messages
* Return proxies synchronously
Otherwise events can be lost.
* Ensure events cannot be missed
* Refactor remaining fills
* Use more up-to-date version of util
For callbackify.
* Wait for dispose to come back before removing
This prevents issues with the "done" event not always being the last
event fired. For example a socket might close and then end, but only
if the caller called end.
* Remove old node-pty tests
* Fix emitting events twice on duplex streams
* Preserve environment when spawning processes
* Throw a better error if the proxy doesn't exist
* Remove rimraf dependency from ide
* Update net.Server.listening
* Use exit event instead of killed
Doesn't look like killed is even a thing.
* Add response timeout to server
* Fix trash
* Require node-pty & spdlog after they get unpackaged
This fixes an error when running in the binary.
* Fix errors in down emitter preventing reconnecting
* Fix disposing proxies when nothing listens to "error" event
* Refactor event tests to use jest.fn()
* Reject proxy call when disconnected
Otherwise it'll wait for the timeout which is a waste of time since we
already know the connection is dead.
* Use nbin for binary packaging
* Remove additional module requires
* Attempt to remove require for local bootstrap-fork
* Externalize fsevents
- It logs the error now.
- For some reason when there is an error node-netstat runs the callback
twice. That resulted in us scheduling an exponentially growing number
of calls which ate up all the CPU (and probably memory eventually).
For now, opted to dispose when there is an error.
* Fixed documentation based on latest release
* Fixed google-cloud documentation steps order
* Edited docs based on the latest release versions
* Make docs more dynamic based on Releases
* Changed ordered list to unordered list
"description": "Hello world! code-server's source code lives here in `src` (see the explorer). It's broadly arranged into browser code, Node code, and code shared between both."
},
{
"file": "src/node/entry.ts",
"line": 157,
"description": "code-server begins execution here. CLI arguments are parsed, special flags like --help are handled, then the HTTP server is started."
},
{
"file": "src/node/cli.ts",
"line": 28,
"description": "This describes all of the code-server CLI options and how they will be parsed."
},
{
"file": "src/node/cli.ts",
"line": 233,
"description": "Here's the actual CLI parser."
},
{
"file": "src/node/settings.ts",
"line": 1,
"description": "code-server maintains a settings file that is read and written here."
},
{
"file": "src/node/app.ts",
"line": 11,
"description": "The core of code-server are HTTP and web socket servers which are created here. They provide authentication, file access, an API, and serve web-based applications like VS Code."
},
{
"file": "src/node/wsRouter.ts",
"line": 38,
"description": "This is an analog to Express's Router that handles web socket routes."
},
{
"file": "src/node/http.ts",
"line": 1,
"description": "This file provides various HTTP utility functions."
},
{
"file": "src/node/coder_cloud.ts",
"line": 9,
"description": "The cloud agent spawned here provides the --link functionality."
"description": "We pass sockets to child processes, however we can't pass TLS sockets so when code-server is handling TLS (via --cert) we use this to create a proxy that can be passed to the child."
},
{
"directory": "src/node/routes",
"line": 1,
"description": "code-server's routes live here in `src/node/routes` (see the explorer)."
},
{
"file": "src/node/routes/index.ts",
"line": 123,
"description": "The architecture of code-server allows it to be extended with applications via plugins. Each application is registered at its own route and handles requests at and below that route. Currently we have only VS Code (although it is not yet actually split out into a plugin)."
},
{
"file": "src/node/plugin.ts",
"line": 103,
"description": "The previously mentioned plugins are loaded here."
},
{
"file": "src/node/routes/apps.ts",
"line": 12,
"description": "This provides a list of the applications registered with code-server."
},
{
"file": "src/node/routes/domainProxy.ts",
"line": 18,
"description": "code-server provides a built-in proxy to help in developing web-based applications. This is the code for the domain-based proxy.\n\nAlso documented here: [https://github.com/cdr/code-server/blob/master/doc/FAQ.md#how-do-i-securely-access-web-services](https://github.com/cdr/code-server/blob/master/doc/FAQ.md#how-do-i-securely-access-web-services)"
},
{
"file": "src/node/routes/pathProxy.ts",
"line": 19,
"description": "Here is the path-based version of the proxy.\n\nAlso documented here: [https://github.com/cdr/code-server/blob/master/doc/FAQ.md#how-do-i-securely-access-web-services](https://github.com/cdr/code-server/blob/master/doc/FAQ.md#how-do-i-securely-access-web-services)"
},
{
"file": "src/node/proxy.ts",
"line": 4,
"description": "Both the domain and path proxy use the single proxy instance created here."
},
{
"file": "src/node/routes/health.ts",
"line": 5,
"description": "A simple endpoint that lets you see if code-server is up.\n\nAlso documented here: [https://github.com/cdr/code-server/blob/master/doc/FAQ.md#healthz-endpoint](https://github.com/cdr/code-server/blob/master/doc/FAQ.md#healthz-endpoint)"
},
{
"file": "src/node/routes/login.ts",
"line": 46,
"description": "code-server supports a password-based login here."
},
{
"file": "src/node/routes/static.ts",
"line": 16,
"description": "This serves static assets. Anything under the code-server directory can be fetched. Anything outside requires authentication."
},
{
"file": "src/node/routes/update.ts",
"line": 10,
"description": "This endpoint lets you query for the latest code-server version. It's used to power the update popup you see in VS Code."
},
{
"file": "src/node/routes/vscode.ts",
"line": 15,
"description": "This is the endpoint that serves VS Code's HTML, handles VS Code's websockets, and handles a few VS Code-specific endpoints for fetching static files."
},
{
"file": "src/node/vscode.ts",
"line": 13,
"description": "The actual VS Code spawn and initialization is handled here. VS Code runs in a separate child process. We communicate via IPC and by passing it web sockets."
},
{
"file": "src/browser/serviceWorker.ts",
"line": 1,
"description": "The service worker only exists to provide PWA functionality."
},
{
"directory": "src/browser/pages",
"line": 1,
"description": "HTML, CSS, and JavaScript for each page lives in here `src/browser/pages` (see the explorer). Currently our HTML uses a simple search and replace template system with variables that {{LOOK_LIKE_THIS}}."
},
{
"file": "src/browser/pages/vscode.html",
"line": 1,
"description": "The VS Code HTML is based off VS Code's own `workbench.html`."
},
{
"directory": "src/browser/media",
"line": 1,
"description": "Static images and the manifest live here in `src/browser/media` (see the explorer)."
},
{
"directory": "lib/vscode",
"line": 1,
"description": "code-server makes use of VS Code's frontend web/remote support. Most of the modifications implement the remote server since that portion of the code is closed source and not released with VS Code.\n\nWe also have a few bug fixes and have added some features (like client-side extensions). See [https://github.com/cdr/code-server/blob/master/doc/CONTRIBUTING.md#modifications-to-vs-code](https://github.com/cdr/code-server/blob/master/doc/CONTRIBUTING.md#modifications-to-vs-code) for a list.\n\nWe make an effort to keep the modifications as few as possible."
"description": "## Commands\n\nTo start developing, make sure you have Node 12+ and the [required dependencies](https://github.com/Microsoft/vscode/wiki/How-to-Contribute#prerequisites) installed. Then, run the following commands:\n\n1. Install dependencies:\n>> yarn\n\n3. Start development mode (and watch for changes):\n>> yarn watch"
},
{
"file": "src/node/app.ts",
"line": 68,
"description": "## Visit the web server\n\nIf all goes well, you should see something like this in your terminal. code-server should be live in development mode.\n\n---\n```bash\n[2020-12-09T21:03:37.156Z] info code-server 3.7.4 development\n[2020-12-09T21:03:37.157Z] info Using user-data-dir ~/.local/share/code-server\n[2020-12-09T21:03:37.165Z] info Using config file ~/.config/code-server/config.yaml\n[2020-12-09T21:03:37.165Z] info HTTP server listening on http://127.0.0.1:8080 \n[2020-12-09T21:03:37.165Z] info - Authentication is enabled\n[2020-12-09T21:03:37.165Z] info - Using password from ~/.config/code-server/config.yaml\n[2020-12-09T21:03:37.165Z] info - Not serving HTTPS\n```\n\n---\n\nIf you have the default configuration, you can access it at [http://localhost:8080](http://localhost:8080)."
},
{
"file": "src/browser/pages/login.html",
"line": 26,
"description": "## Make a change\n\nThis is the login page, let's make a change and see it update on our web server! Perhaps change the text :)\n\n```html\n<div class=\"sub\">Modifying the login page 👨🏼💻</div>\n```\n\nReminder, you can likely preview at [http://localhost:8080](http://localhost:8080)"
},
{
"file": "src/node/app.ts",
"line": 62,
"description": "## That's it!\n\n\nThat's all there is to it! When this tour ends, your terminal session may stop, but just use `yarn watch` to start developing from here on out!\n\n\nIf you haven't already, be sure to check out these resources:\n- [Tour: Contributing](command:codetour.startTourByTitle?[\"Contributing\")\n- [Docs: FAQ.md](https://github.com/cdr/code-server/blob/master/doc/FAQ.md)\n- [Docs: CONTRIBUTING.md](https://github.com/cdr/code-server/blob/master/doc/CONTRIBUTING.md)\n- [Community: GitHub Discussions](https://github.com/cdr/code-server/discussions)\n- [Community: Slack](https://community.coder.com)"
Run [VS Code](https://github.com/Microsoft/vscode) on any machine anywhere and access it in the browser.
`code-server` is [VS Code](https://github.com/Microsoft/vscode) running on a remote server, accessible through the browser.

Try it out:
```bash
docker run -t -p 127.0.0.1:8443:8443 -v "${PWD}:/root/project" codercom/code-server --allow-http --no-auth
```
## Highlights
- Code on your Chromebook, tablet, and laptop with a consistent dev environment.
-If you have a Windows or Mac workstation, more easily develop for Linux.
-Take advantage of large cloud servers to speed up tests, compilations, downloads, and more.
- Preserve battery life when you're on the go.
- All intensive computation runs on your server.
- You're no longer running excess instances of Chrome.

- Code on any device with a consistent development environment
-Use cloud servers to speed up tests, compilations, downloads, and more
-Preserve battery life when you're on the go; all intensive tasks run on your server
## Getting Started
### Hosted
There are two ways to get started:
[Try `code-server` now](https://coder.com/signup) for free at coder.com.
1. Using the [install script](./install.sh), which automates most of the process. The script uses the system package manager (if possible)
2. Manually installing code-server; see [Installation](./doc/install.md) for instructions applicable to most use cases
### Docker
If you choose to use the install script, you can preview what occurs during the install process:
See docker oneliner mentioned above. Dockerfile is at [/Dockerfile](/Dockerfile).
```bash
curl -fsSL https://code-server.dev/install.sh | sh -s -- --dry-run
```
### Binaries
To install, run:
1. [Download a binary](https://github.com/codercom/code-server/releases) (Linux and OS X supported. Windows coming soon)
2. Start the binary with the project directory as the first argument
```bash
curl -fsSL https://code-server.dev/install.sh | sh
```
```
code-server <initial directory to open>
```
> You will be prompted to enter the password shown in the CLI
`code-server` should now be running at https://localhost:8443.
When done, the install script prints out instructions for running and starting code-server.
> code-server uses a self-signed SSL certificate that may prompt your browser to ask you some additional questions before you proceed. Please [read here](doc/self-hosted/index.md) for more information.
We also have an in-depth [setup and configuration](./doc/guide.md) guide.
For detailed instructions and troubleshooting, see the [self-hosted quick start guide](doc/self-hosted/index.md).
### Cloud Program ☁️
Quickstart guides for [Google Cloud](doc/admin/install/google_cloud.md), [AWS](doc/admin/install/aws.md), and [Digital Ocean](doc/admin/install/digitalocean.md).
We're working on a cloud platform that makes deploying and managing code-server easier.
Consider running code-server with the beta flag `--link` if you don't want to worry about
How to [secure your setup](/doc/security/ssl.md).
- TLS
- Authentication
- Port Forwarding
## Development
```bash
$ code-server --link
Proxying code-server to Coder Cloud, you can access your IDE at https://valmar-jon.cdr.co
```
### Known Issues
## FAQ
- Creating custom VS Code extensions and debugging them doesn't work.
See [./doc/FAQ.md](./doc/FAQ.md).
### Future
## Want to help?
- Windows support.
- Electron and Chrome OS applications to bridge the gap between local<->remote.
- Run VS Code unit tests against our builds to ensure features work as expected.
See [CONTRIBUTING](./doc/CONTRIBUTING.md) for details.
## Contributing
## Hiring
Development guides are coming soon.
We ([@cdr](https://github.com/cdr)) are looking for engineers to help [maintain
code-server](https://jobs.lever.co/coder/e40becde-2cbd-4885-9029-e5c7b0a734b8), innovate on open source, and streamline dev workflows.
## License
Our main office is in Austin, Texas. Remote is ok as long as
you're in North America or Europe.
[MIT](LICENSE)
Please get in [touch](mailto:jobs@coder.com) with your resume/GitHub if interested.
## Enterprise
## For Organizations
Visit [our enterprise page](https://coder.com/enterprise) for more information about our enterprise offering.
## Commercialization
If you would like to commercialize code-server, please contact contact@coder.com.
Visit [our website](https://coder.com) for more information about remote development for your organization or enterprise.
1. Microsoft/vscode version 1.47.0 (https://github.com/Microsoft/vscode)
%% Microsoft/vscode NOTICES AND INFORMATION BEGIN HERE
=========================================
MIT License
Copyright (c) 2015 - present Microsoft Corporation
Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
This directory contains scripts used for code-server's continuous integration infrastructure.
Some of these scripts contain more detailed documentation and options
in header comments.
Any file or directory in this subdirectory should be documented here.
- [./ci/lib.sh](./lib.sh)
- Contains code duplicated across these scripts.
## Publishing a release
Make sure you have `$GITHUB_TOKEN` set and [hub](https://github.com/github/hub) installed.
1. Update the version of code-server and make a PR.
1. Update in `package.json`
2. Update in [./doc/install.md](../doc/install.md)
3. Update in [./ci/helm-chart/README.md](../ci/helm-chart/README.md)
- Remember to update the chart version as well on top of appVersion in `Chart.yaml`.
- Run `rg -g '!yarn.lock' -g '!*.svg' '3\.7\.5'` to ensure all values have been
changed. Replace the numbers as needed.
2. GitHub actions will generate the `npm-package`, `release-packages` and `release-images` artifacts.
1. You do not have to wait for these.
3. Run `yarn release:github-draft` to create a GitHub draft release from the template with
the updated version.
1. Summarize the major changes in the release notes and link to the relevant issues.
4. Wait for the artifacts in step 2 to build.
5. Run `yarn release:github-assets` to download the `release-packages` artifact.
- It will upload them to the draft release.
6. Run some basic sanity tests on one of the released packages.
- Especially make sure the terminal works fine.
7. Make sure the github release tag is the commit with the artifacts. This is a bug in
`hub` where uploading assets in step 5 will break the tag.
8. Publish the release and merge the PR.
1. CI will automatically grab the artifacts and then:
1. Publish the NPM package from `npm-package`.
2. Publish the Docker Hub image from `release-images`.
9. Update the AUR package.
- Instructions on updating the AUR package are at [cdr/code-server-aur](https://github.com/cdr/code-server-aur).
10. Wait for the npm package to be published.
11. Update the homebrew package.
- Send a pull request to [homebrew-core](https://github.com/Homebrew/homebrew-core) with the URL in the [formula](https://github.com/Homebrew/homebrew-core/blob/master/Formula/code-server.rb) updated.
## dev
This directory contains scripts used for the development of code-server.
- [./ci/dev/image](./dev/image)
- See [./doc/CONTRIBUTING.md](../doc/CONTRIBUTING.md) for docs on the development container.
- Have [yarn](https://classic.yarnpkg.com/en/) installed (which is used to install JS packages and run development scripts)
- Have [nfpm](https://github.com/goreleaser/nfpm) (which is used to build `.deb` and `.rpm` packages and [jq](https://stedolan.github.io/jq/) (used to build code-server releases) installed
The [CI container](../ci/images/debian8/Dockerfile) is a useful reference for all
of the dependencies code-server uses.
## Development Workflow
```shell
yarn
yarn watch
# Visit http://localhost:8080 once the build is completed.
```
To develop inside an isolated Docker container:
```shell
./ci/dev/image/run.sh yarn
./ci/dev/image/run.sh yarn watch
```
`yarn watch` will live reload changes to the source.
### Updating VS Code
If you need to update VS Code, you can update the subtree with one line. Here's an example using the version 1.52.1
```shell
git subtree pull --prefix lib/vscode vscode release/1.52 --squash --message "Update VS Code to 1.52.1"
```
## Build
You can build using:
```shell
./ci/dev/image/run.sh ./ci/steps/release.sh
```
Run your build with:
```shell
cd release
yarn --production
# Runs the built JavaScript with Node.
node .
```
Build the release packages (make sure that you run `./ci/steps/release.sh` first):
# The standalone release is in ./release-standalone
# .deb, .rpm and the standalone archive are in ./release-packages
```
The `release.sh` script is equal to running:
```shell
yarn
yarn build
yarn build:vscode
yarn release
```
And `release-packages.sh` is equal to:
```shell
yarn release:standalone
yarn test:standalone-release
yarn package
```
For a faster release build, you can run instead:
```shell
KEEP_MODULES=1 ./ci/steps/release.sh
node ./release
```
## Structure
The `code-server` script serves an HTTP API for login and starting a remote VS Code process.
The CLI code is in [./src/node](./src/node) and the HTTP routes are implemented in
[./src/node/app](./src/node/app).
Most of the meaty parts are in the VS Code portion of the codebase under [./lib/vscode](./lib/vscode), which we described next.
### Modifications to VS Code
In v1 of code-server, we had a patch of VS Code that split the codebase into a front-end
and a server. The front-end consisted of all UI code, while the server ran the extensions
and exposed an API to the front-end for file access and all UI needs.
Over time, Microsoft added support to VS Code to run it on the web. They have made
the front-end open source, but not the server. As such, code-server v2 (and later) uses
the VS Code front-end and implements the server. We do this by using a git subtree to fork and modify VS Code. This code lives under [./lib/vscode](./lib/vscode).
Some noteworthy changes in our version of VS Code:
- Adding our build file, which includes our code and VS Code's web code
- Allowing multiple extension directories (both user and built-in)
- Modifying the loader, websocket, webview, service worker, and asset requests to
use the URL of the page as a base (and TLS, if necessary for the websocket)
- Sending client-side telemetry through the server
- Allowing modification of the display language
- Making it possible for us to load code on the client
- Making extensions work in the browser
- Making it possible to install extensions of any kind
- Fixing issue with getting disconnected when your machine sleeps or hibernates
- Adding connection type to web socket query parameters
As the web portion of VS Code matures, we'll be able to shrink and possibly
eliminate our modifications. In the meantime, upgrading the VS Code version requires
us to ensure that our changes are still applied and work as intended. In the future,
we'd like to run VS Code unit tests against our builds to ensure that features
work as expected.
**Note**: We have [extension docs](../ci/README.md) on the CI and build system.
If the functionality you're working on does NOT depend on code from VS Code, please
move it out and into code-server.
### Currently Known Issues
- Creating custom VS Code extensions and debugging them doesn't work
- Extension profiling and tips are currently disabled
This tutorial shows you how to deploy `code-server` on an EC2 AWS instance.
If you're just starting out, we recommend [installing code-server locally](../../self-hosted/index.md). It takes only a few minutes and lets you try out all of the features. You can also try out the IDE on a container hosted [by Coder](http://coder.com/signup)
---
## Deploy to EC2
### Use the AWS wizard
- Click **Launch Instance** from your [EC2 dashboard](https://console.aws.amazon.com/ec2/v2/home).
- Select the Ubuntu Server 16.04 LTS (HVM), SSD Volume Type (`ami-0f9cf087c1f27d9b1)` at this time of writing)
- Select an appropriate instance size (we recommend t2.medium/large, depending on team size and number of repositories/languages enabled), then **Next: Configure Instance Details**
- Select **Next: ...** until you get to the **Configure Security Group** page, then add the default **HTTP** rule (port range "80", source "0.0.0.0/0, ::/0")
> Rules with source of 0.0.0.0/0 allow all IP addresses to access your instance. We recommend setting [security group rules](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-network-security.html?icmpid=docs_ec2_console) to allow access from known IP addresses only.
- Click **Launch**
- You will be prompted to create a key pair
> A key pair consists of a public key that AWS stores, and a private key file that you store. Together, they allow you to connect to your instance securely. For Windows AMIs, the private key file is required to obtain the password used to log into your instance. For Linux AMIs, the private key file allows you to securely SSH into your instance.
- From the dropdown choose "create a new pair", give the key pair a name
- Click **Download Key Pair**
> This is necessary before you proceed. A `.pem` file will be downloaded. make sure you store is in a safe location because it can't be retrieved once we move on.
- Finally, click **Launch Instances**
---
### SSH Into EC2 Instance
- First head to your [EC2 dashboard](https://console.aws.amazon.com/ec2/v2/home) and choose instances from the left panel
- In the description of your EC2 instance copy the public DNS (iPv4) address using the copy to clipboard button
- Open a terminal on your computer and use the following command to SSH into your EC2 instance
```
ssh -i "path/to/your/keypair.pem" ubuntu@(paste the public DNS here)
- You should see a prompt for your EC2 instance like so<img src="../../assets/aws_ubuntu.png">
- At this point it is time to download the `code-server` binary. We will of course want the linux version. Make sure you copy the link for the latest linux version on our [releases page](https://github.com/codercom/code-server/releases)
- If you run into any permission errors, make the binary executable by running:
```
chmod +x code-server-linux
```
> To ensure the connection between you and your server is encrypted view our guide on [securing your setup](../security/ssl.md)
- Finally, run
```
sudo ./code-server-linux -p 80
```
- When you visit the public IP for your AWS instance, you will be greeted with this page. Code-server is using a self-signed SSL certificate for easy setup. To proceed to the IDE, click **"Advanced"**<img src ="../../assets/chrome_warning.png">
- Then click **"proceed anyway"**<img src="../../assets/chrome_confirm.png">
> For instructions on how to keep the server running after you end your SSH session please checkout [how to use systemd](https://www.linode.com/docs/quick-answers/linux/start-service-at-boot/) to start linux based services if they are killed
> The `-p 80` flag is necessary in order to make the IDE accessible from the public IP of your instance (also available from the description in the instances page.
---
> NOTE: If you get stuck or need help, [file an issue](https://github.com/codercom/code-server/issues/new?&title=Improve+self-hosted+quickstart+guide), [tweet (@coderhq)](https://twitter.com/coderhq) or [email](mailto:support@coder.com?subject=Self-hosted%20quickstart%20guide).
This tutorial shows you how to deploy `code-server` to a single node running on DigitalOcean.
If you're just starting out, we recommend [installing code-server locally](../../self-hosted/index.md). It takes only a few minutes and lets you try out all of the features. You can also try out the IDE on a container hosted [by Coder](http://coder.com/signup)
---
## Use the "Create Droplets" wizard
[Open your DigitalOcean dashboard](https://cloud.digitalocean.com/droplets/new) to create a new droplet
- **Choose an image -** Select the **Distributions** tab and then choose Ubuntu
- **Choose a size -** We recommend at least 4GB RAM and 2 CPU, more depending on team size and number of repositories/languages enabled.
- Launch your instance
- Open a terminal on your computer and SSH into your instance
> example: ssh root@203.0.113.0
- Once in the SSH session, visit code-server [releases page](https://github.com/codercom/code-server/releases/) and copy the link to the download for the latest linux release
- In the shell run the below command with the URL from your clipboard
- If you run into any permission errors when attempting to run the binary:
```
chmod +x code-server-linux
```
> To ensure the connection between you and your server is encrypted view our guide on [securing your setup](../security/ssl.md)
- Finally start the code-server
```
sudo ./code-server-linux -p 80
```
> For instructions on how to keep the server running after you end your SSH session please checkout [how to use systemd](https://www.linode.com/docs/quick-answers/linux/start-service-at-boot/) to start linux based services if they are killed
- When you visit the public IP for your Digital Ocean instance, you will be greeted with this page. Code-server is using a self-signed SSL certificate for easy setup. To proceed to the IDE, click **"Advanced"**<img src ="../../assets/chrome_warning.png">
- Then click **"proceed anyway"**<img src="../../assets/chrome_confirm.png">
---
> NOTE: If you get stuck or need help, [file an issue](https://github.com/codercom/code-server/issues/new?&title=Improve+self-hosted+quickstart+guide), [tweet (@coderhq)](https://twitter.com/coderhq) or [email](mailto:support@coder.com?subject=Self-hosted%20quickstart%20guide).
This tutorial shows you how to deploy `code-server` to a single node running on Google Cloud.
If you're just starting out, we recommend [installing code-server locally](../../self-hosted/index.md). It takes only a few minutes and lets you try out all of the features. You can also try out the IDE on a container hosted [by Coder](http://coder.com/signup)
---
## Deploy to Google Cloud VM
> Pre-requisite: Please [set up Google Cloud SDK](https://cloud.google.com/sdk/docs/) on your local machine
- [Open your Google Cloud console](https://console.cloud.google.com/compute/instances) to create a new VM instance and click **Create Instance**
- Choose an appropriate machine type (we recommend 2 vCPU and 7.5 GB RAM, more depending on team size and number of repositories/languages enabled)
- Choose Ubuntu 16.04 LTS as your boot disk
- Check the boxes for **Allow HTTP traffic** and **Allow HTTPS traffic** in the **Firewall** section
- Create your VM, and **take note** of it's public IP address.
- Copy the link to download the latest Linux binary from our [releases page](https://github.com/codercom/code-server/releases)
3. Make the binary executable if you run into any errors regarding permission:
```
chmod +x code-server-linux
```
> To ensure the connection between you and your server is encrypted view our guide on [securing your setup](../security/ssl.md)
4. Start the code-server
```
sudo ./code-server-linux -p 80
```
> For instructions on how to keep the server running after you end your SSH session please checkout [how to use systemd](https://www.linode.com/docs/quick-answers/linux/start-service-at-boot/) to start linux based services if they are killed
5. Access code-server from the public IP of your Google Cloud instance we noted earlier in your browser.
> example: 32.32.32.234
6. You will be greeted with this page. Code-server is using a self-signed SSL certificate for easy setup. To proceed to the IDE, click **"Advanced"**<img src ="../../assets/chrome_warning.png">
7. Then click **"proceed anyway"**<img src="../../assets/chrome_confirm.png">
---
> NOTE: If you get stuck or need help, [file an issue](https://github.com/codercom/code-server/issues/new?&title=Improve+self-hosted+quickstart+guide), [tweet (@coderhq)](https://twitter.com/coderhq) or [email](mailto:support@coder.com?subject=Self-hosted%20quickstart%20guide).
7. We highly recommend switching the persistent disk to an SSD of at least 32 GB.
- Click `Change` under `Boot Disk` and change the type to `SSD Persistent Disk` and the size
to `32`.
- You can always grow your disk later.
8. Navigate to `Networking -> Network interfaces` and edit the existing interface
to use a static external IP.
- Click done to save network interface changes.
9. If you do not have a [project wide SSH key](https://cloud.google.com/compute/docs/instances/adding-removing-ssh-keys#project-wide), navigate to `Security -> SSH Keys` and add your public key there.
10. Click create!
Remember, you can shutdown your server when not in use to lower costs.
We highly recommend learning to use the [`gcloud`](https://cloud.google.com/sdk/gcloud) cli
to avoid the slow dashboard.
## 2. Install code-server
We have a [script](../install.sh) to install `code-server` for Linux, macOS and FreeBSD.
It tries to use the system package manager if possible.
First run to print out the install process:
```bash
curl -fsSL https://code-server.dev/install.sh | sh -s -- --dry-run
```
Now to actually install:
```bash
curl -fsSL https://code-server.dev/install.sh | sh
```
The install script will print out how to run and start using `code-server`.
Docs on the install script, manual installation and docker image are at [./install.md](./install.md).
## 3. Expose code-server
**Never**, **ever** expose `code-server` directly to the internet without some form of authentication
and encryption as someone can completely takeover your machine with the terminal.
By default, `code-server` will enable password authentication which will require you to copy the
password from the`code-server`config file to login. It will listen on`localhost` to avoid exposing
itself to the world. This is fine for testing but will not work if you want to access `code-server`
from a different machine.
There are several approaches to securely operating and exposing `code-server`.
**tip**: You can list the full set of `code-server` options with `code-server --help`
### SSH forwarding
We highly recommend this approach for not requiring any additional setup, you just need an
SSH server on your remote machine. The downside is you won't be able to access `code-server`
on any machine without an SSH client like on iPad. If that's important to you, skip to [Let's Encrypt](#lets-encrypt).
First, ssh into your instance and edit your `code-server` config file to disable password authentication.
```bash
# Replaces "auth: password" with "auth: none" in the code-server config.
sed -i.bak 's/auth: password/auth: none/' ~/.config/code-server/config.yaml
```
Restart `code-server` with (assuming you followed the guide):
```bash
sudo systemctl restart code-server@$USER
```
Now forward local port 8080 to `127.0.0.1:8080` on the remote instance by running the following command on your local machine.
<!-- START doctoc generated TOC please keep comment here to allow auto update -->
<!-- DON'T EDIT THIS SECTION, INSTEAD RE-RUN doctoc TO UPDATE -->
# iPad
- [Known Issues](#known-issues)
- [How to access code-server with a self signed certificate on iPad?](#how-to-access-code-server-with-a-self-signed-certificate-on-ipad)
- [Servediter iPad App](#servediter-ipad-app)
- [Raspberry Pi USB-C Network](#raspberry-pi-usb-c-network)
- [Recommendations](#recommendations)
- [By 2022 iPad coding more desirable on Arm Macs](#by-2022-ipad-coding-more-desirable-on-arm-macs)
<!-- END doctoc generated TOC please keep comment here to allow auto update -->
## Known Issues
- Getting self signed certificates certificates to work is involved, see below.
- Keyboard issues
- May disappear sometimes [#1313](https://github.com/cdr/code-server/issues/1313), [#979](https://github.com/cdr/code-server/issues/979)
- Some short cuts expectations may not be met
-`command + n` opens new browser window instead of new file and difficult to even set to another quick key
- In general it's just note worthy you most likely will need to edit keyboard shortcuts
- No escape key by default on Magic Keyboard but everyone sets the globe key to be an escape key
- Opinion: It's actually an awesome joy having the escape key at bottom of keyboard
- Trackpad scrolling does not work [#1455](https://github.com/cdr/code-server/issues/1455)
- [Bug tracking of a WebKit fix here](https://bugs.webkit.org/show_bug.cgi?id=210071#c13)
- [tracking of WebKit patch](https://trac.webkit.org/changeset/270712/webkit)
- Alternative: Install line-jump extension and use keyboard to nav by jumping large amount of lines
- Alternative: Just use touch scrolling
- See [issues tagged with the iPad label](https://github.com/cdr/code-server/issues?q=is%3Aopen+is%3Aissue+label%3AiPad) for more.
## How to access code-server with a self signed certificate on iPad?
Accessing a self signed certificate on iPad isn't as easy as accepting through all
the security warnings. Safari will prevent WebSocket connections unless the certificate
is installed as a profile on the device.
The below assumes you are using the self signed certificate that code-server
generates for you. If not, that's fine but you'll have to make sure your certificate
abides by the following guidelines from Apple: https://support.apple.com/en-us/HT210176
**note**: Another undocumented requirement we noticed is that the certificate has to have `basicConstraints=CA:true`.
The following instructions assume you have code-server installed and running
with a self signed certificate. If not, please first go through [./guide.md](./guide.md)!
**warning**: Your iPad must access code-server via a domain name. It could be local
DNS like `mymacbookpro.local` but it must be a domain name. Otherwise Safari will
refuse to allow WebSockets to connect.
1. Your certificate **must** have a subject alt name that matches the hostname
at which you will access code-server from your iPad. You can pass this to code-server
so that it generates the certificate correctly with `--cert-host`.
2. Share your self signed certificate with the iPad.
- code-server will print the location of the certificate it has generated in the logs.
```
[2020-10-30T08:55:45.139Z] info - Using generated certificate and key for HTTPS: ~/.local/share/code-server/mymbp_local.crt
```
- You can mail it to yourself or if you have a Mac, it's easiest to just Airdrop to the iPad.
3. When opening the `*.crt` file, you'll be prompted to go into settings to install.
4. Go to `Settings -> General -> Profile`, select the profile and then hit `Install`.
- It should say the profile is verified.
5. Go to `Settings -> About -> Certificate Trust Settings` and enable full trust for
the certificate. [more apple support here](https://support.apple.com/en-us/HT204477)
6. Now you can access code-server! 🍻
### Servediter iPad App
If you are unable to get the self signed certificate working or you do not have a domain
name to use, you can use the Servediter iPad App instead!
**note**: This is not an officially supported app by the code-server team!
Download [Serveediter](https://apps.apple.com/us/app/servediter-for-code-server/id1504491325) from the
App Store and then input your server information. If you are running a local server or mabye a usb-c
connected Raspberry Pi, you will input your settings into "Self Hosted Server".
## Raspberry Pi USB-C Network
It is a bit out of scope for this project, however, great success is being reported using iPad on the go with just a single USB-C cable connected to a Raspberry Pi both powering and supplying direct network access. Many support articles already exist but the key steps boil down to turning on Network over USB-C on the Raspberry Pi itself and the rest of the steps are just like getting Code Server running any where else.
Resources worthy of review:
- [General intro to Pi as an iPad accessory](https://www.youtube.com/watch?v=IR6sDcKo3V8)
- [iPad with Pi FAQ](https://www.youtube.com/watch?v=SPSlyqo5Q2Q)
- [Technical guide to perform the steps](https://www.geeky-gadgets.com/connect-a-raspberry-pi-4-to-an-ipad-pro-21-01-2020/)
> Here are my keys to success. I bought a 4" touch screen with fan included that attaches as a case to the Pi. I use the touch screen for anytime I have connection issues, otherwise I turn off the Pi screen. I gave my Pi a network name so I can easily connect at home on wifi or when on go with 1 usb-c cable that supplys both power and network connectivity. Lastly, not all usb-c cables are equal and not all will work so try different usb-c cables if you are going mad (confirm over wifi first then move to cable).
Once you have code-server accessible to your iPad a few things could help save you time:
- Use multi task mode to make code changes and see browser at the same time
- Prevents iOs background dropping an App's state if you are full screen switching between code-server and browser
- Be sure you are using the debug/terminal that is built into VS Code so that you don’t need another terminal app running
- Again, prevents switching between full screen app and losing your view to iOs background app memory management
- You should be of a mindset willing to deal and adapt with differences in having an imperfect experience, for the perceived joyful benefits of interacting with your computer in more intuitive ways
## By 2022 iPad coding more desirable on Arm Macs
> This section is generalized opinions intended to inform fellow Apple product consumers of perceived over time changes coming down the line
The general feeling from overall Apple movements recently, is that the Mac arm processors are in fact helping support the direction of having Macs with touch screens. Many great YouTube videos of interest call out highly suggestive evidence. In the past Apple has hard declared reasons of body fatigue and such as why not to encourage nor further developments on the iPad touch experience mixed with a keyboard/mouse/trackpad. Regardless, products and software have been released further supporting just that very experience.
The iPad coding experience has been a joy for some of us that are willing to trade an imperfect experience for a uniquely effective focus driven experience. Note worthy, some of us think it's a trashy waste of time. This experience is undoubtably going to get better just by the work that can be seen by all parties, even in our own code-server attempt to make it better.
Lastly, it is note worthy that if you have decided to incorporate a Raspberry Pi into you iPad coding experience, they are Arm processors. You are perfectly lined up with the future of Macs as well.
code-server has the ability to secure your connection between client and server using SSL/TSL certificates. By default, the server will start with an unencrypted connection. We recommend Self-signed TLS/SSL certificates for personal use of code-server or within an organization.
This guide will show you how to create a self-signed certificate and start code-server using your certificate/key.
## TLS / HTTPS
You can specify any location that you want to save the certificate and key. In this example, we will navigate to the root directory, create a folder called `certs` and cd into it.
```shell
mkdir ~/certs &&cd ~/certs
```
If you don't already have a TLS certificate and key, you can generate them with the command below. They will be placed in `~/certs`
You will be prompted to add some identifying information about your organization
```shell
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code)[AU]:US
State or Province Name (full name)[Some-State]:TX
Locality Name (eg, city)[]:Austin
Organization Name (eg, company)[Coder Technologies]:Coder
Organizational Unit Name (eg, section)[]:Docs
Common Name (e.g. server FQDN or YOUR name)[]:hostname.example.com
Email Address []:admin@example.com
```
>If you already have a TLS certificate and key, you can simply reference them in the `--cert` and `--cert-key` flags when launching code-server
## Starting code-server with certificate and key
1. At the end of the path to your binary, add the following flags followed by the path to your certificate and key like so. Then press enter to run code-server.
2. After that you will be running a secure code-server.
> You will know your connection is secure if the lines `WARN No certificate specified. This could be insecure. WARN Documentation on securing your setup: https://coder.com/docs` no longer appear.
## Other options
For larger organizations you may wish to rely on a Certificate Authority as opposed to a self-signed certificate. For more information on generating free and open certificates for your site, please check out EFF's [certbot](https://certbot.eff.org/). Certbot is a cli to generate certificates using [LetsEncrypt](https://letsencrypt.org/).
[code-server](https://coder.com) is used by developers at Azure, Google, Reddit, and more to give them access to VS Code in the browser.
## Quickstart guide
> NOTE: If you get stuck or need help, [file an issue](https://github.com/codercom/code-server/issues/new?&title=Improve+self-hosted+quickstart+guide), [tweet (@coderhq)](https://twitter.com/coderhq) or [email](mailto:support@coder.com?subject=Self-hosted%20quickstart%20guide).
This document pertains to Coder specific implementations of VS Code. For documentation on how to use VS Code itself, please refer to the official [documentation for VS Code](https://code.visualstudio.com/docs)
It takes just a few minutes to get your own self-hosted server running. If you've got a machine running macOS, Windows, or Linux, you're ready to start the binary which listens on port `8443` by default.
<!--
DO NOT CHANGE THIS TO A CODEBLOCK.
We want line breaks for readability, but backslashes to escape them do not work cross-platform.
This uses line breaks that are rendered but not copy-pasted to the clipboard.
-->
1. Visit [the releases](https://github.com/codercom/code-server/releases) page and download the latest cli for your operating system
2. Double click the executable to run in the current directory
3. Copy the password that appears in the cli<img src="../assets/cli.png">
4. In your browser navigate to `localhost:8443`
5. Paste the password from the cli into the login window<img src="../assets/server-password-modal.png">
> NOTE: Be careful with your password as sharing it will grant those users access to your server's file system
### Things to know
- When you visit the IP for your code-server, you will be greeted with this page. Code-server is using a self-signed SSL certificate for easy setup. To proceed to the IDE, click **"Advanced"**<img src ="../assets/chrome_warning.png">
- Then click **"proceed anyway"**<img src="../assets/chrome_confirm.png">
code-server can be ran with a number of arguments to customize your working directory, host, port, and SSL certificate.
```
USAGE
$ code-server [WORKDIR]
ARGUMENTS
WORKDIR [default: (directory to binary)] Specify working dir
OPTIONS
-d, --data-dir=data-dir
-h, --host=host [default: 0.0.0.0]
-o, --open Open in browser on startup
-p, --port=port [default: 8443] Port to bind on
-v, --version show CLI version
--allow-http
--cert=cert
--cert-key=cert-key
--help show CLI help
--no-auth
--password=password
```
### Data directory
Use `code-server -d (path/to/directory)` or `code-server --data-dir=(path/to/directory)`, excluding the parentheses to specify the root folder that VS Code will start in
### Host
By default, code-server will use `0.0.0.0` as its address. This can be changed by using `code-server -h` or `code-server --host=` followed by the address you want to use.
> Example: `code-server -h 127.0.0.1`
### Open
You can have the server automatically open the VS Code in your browser on startup by using the `code server -o` or `code-server --open` flags
### Port
By default, code-server will use `8443` as its port. This can be changed by using `code-server -p` or `code-server --port=` followed by the port you want to use.
> Example: `code-server -p 9000`
### Cert and Cert Key
To encrypt the traffic between the browser and server use `code-server --cert=` followed by the path to your `.cer` file. Additionally, you can use certificate keys with `code-server --cert-key` followed by the path to your `.key` file.
> Example (certificate and key): `code-server --cert /etc/letsencrypt/live/example.com/fullchain.cer --cert-key /etc/letsencrypt/live/example.com/fullchain.key`
> To ensure the connection between you and your server is encrypted view our guide on [securing your setup](../security/ssl.md)
### Nginx Reverse Proxy
Nginx is for reverse proxy. Here is a example virtual host that works with code-server. Please also pass --allow-http. You can also use certbot by EFF to get a ssl certificates for free.
```
server {
listen 80;
listen [::]:80;
server_name code.example.com code.example.org;
location / {
proxy_pass http://localhost:8443/;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection upgrade;
}
}
```
### Help
Use `code-server -h` or `code-server --help` to view the usage for the cli. This is also shown at the beginning of this section.
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.